<bgdev />free

| |  


All tags 2023 9may ai algorithm alpha amd american api argon2 arm asm asmbb assembler attachment awareness balgaria bay888 bcrypt bender beta bgdev-next bgdev-next.👍 big.data bitchnigga bitcoin bmw boi borg brexit bug bulgaria business c cad chat cloud computer-names console crossorigin deprivation desktop dna dotnet email eupl falling feature forum foundation fp fresh fun game github goats google gpl gpt gpt.3.5 gypsies happiness harvard hash improvement include investment it java javascript js kleta kleta.maqka.balg lambi language learning leftovers legend level levenshtein.dist libx license linkedlist linux ma mcafee mele microsoft minimag minimalism negro net nginx nigga not.a.bug oop paradigm parler patterns perception persuasion pipe play.station politics populi pornhub pow pro programming protonmail python reba rust sci-fi scripting seks seo server shell sleep smartbeauty soft-skills sqlite srabska sse starship sugerface syntax tablet tailwindcss telegram theme thug troll80lvl tutanota typescript uacme ui uk unix untermensch upload uptime usa utilities ux vb via viber virtual.reality vox vps vulnerable war wasm weapons-grade web windows word x86 xbox xss youtube zig ziglang Übermensch БОКЕБЪЛГАРИН БЪ БЪлгария Белезниците Били Били.Белезниците БялДонор Веган Виста Възраждане ГЛУПАК Гана Глиста ЕС Казарма Копейкин Мода.и.овча.мисъ НЕКАДЪРНИК НРБ ПО-ЗЛЕ.И.ОТ.РАБИ Подкасти Разни Румен СИК СКУМ СетенЧук Скум ТИР Туче Украйна Урсула Яначков авангард аз айфонджия алгоритми амбиции анархизъм антиваксъри армения аудио аутисти бази.данни бакъп без без.пръчове безпросвета бенчмарк биготи биомаса бира боклук борисов ботев брадва булшит бъг бъгове бял ваксина вандал век венерика викинги вицове вишу война вървежен гана ганорник гей гейщина германия герои гешев глупак говеда групировка гюбек данъкоплатец двойни.стандарти дедотия демокрация дизайн дисциплина добитък докери долар донори држава дришльо дрон ебане еврогейски.съюз езици експеримент електроника електроника.s2 емиграция ендпойнт енум ерген ергономия жалкар задача затоплизъм защита здраве златен злато игри идеали идиократ идиократи идиокрация идиот избори избори.рабин изкуство икономика имбецили имейл инвестиране инокулация инструмента интервю ипад искам.да.си.реда казах камшикодържач капитализъм карабах караница картечница кино клавиатура ковид19 колайдер колям.кур комари комплексар комунизъм консолидация конспирации космонавтика кофа кофит-19 краставица криптовалути курви кучелюбци лайно лаладжия лаптоп либерастия литература лоши.практики луд лъжеучени лъжец любов майни майтапи малоумници мафия мениджмънт месо местене метавселена метафизика механика мистика мисъл мода мода.овча.мисъл модерация морал мутра мутри наука национализъм не.it негър некадърник некадърници неон нидерландия овча овчи олигофрени организация офтопик парички партия педал пенджури пенсия пишока плюскане победа погромист поезия политика порно посредствен почивка празници прасе превод предалщина програмиране проект проста простотии против.правилата проф пръч пръч.дришльо пръчка психика психични.болести психология пустиняк путин путката путьо рабин рабин.е.шибан.пе работа радост разврат разни разработка расизъм резерват рейтинг реклама рекламен религия рест ризи ропче ропчета русия руски.език рутина самоковска сасипаха секира село селяндур сериали сериозно.програм сетен сеянин симулация скопяване скръм слушалки сортиране софия софтуер софтуни социализъм спектрометър спринтове сране стандарти стил стуйо стюи сушилня сцена съвет съм сън сървър сърничка таб ташаци телевизия тема територията терминология термояд технологии титли традиция тролинг тръмп туба туче тъпак тъпанари тъпня уиндоус украйна умнокрасивци фалит фантастика фашизъм фейк.акаунти физика филми форум форумни.проекти футбол хазарт хамали харабия хардуер хахаха хомофобия хостинг храна хумор цайко цайси целофан цензура цензурра циганин чалга чалгар чекии чернокраки честота чипове чнг чужбина чук шпация щайга юан яката яко ям 🔨 😂 🪓


Задача НЕ за интервю

  

0 1 2 3 4 ...17 18 19 20 21 ...32 33 34 35 36


  |  Създадено на 19.09.2020, видяно: 1852 пъти. #11143
ФейкПрофил

Как ще го смятате, по възможност без "фактори"? :)

как :)

Чакам вие да кажете първо, за да не ви вкарвам в коловоз. Моето решение определено не е оптимално.



  bvbfan  Създадено на 20.09.2020, видяно: 1832 пъти. #11150

SQLite, blob за полетата, Levenstein в кода и дерзаеш.



  johnfound  Създадено на 20.09.2020, видяно: 1828 пъти. #11151
|

Грешките може да са до над 100, но да предположим че ни интересува match с до 64 грешки.

Това какво значи? Че може да се дават като решение стрингове чието растояние на Левенщайн всъщност не е най-малкото в множество А?

Или че просто растоянието на Левенщайн трябва да се смята приблизително и някой път може да е грешно сметнато, но все пак е най-малкото сред грешно сметнатите?

Между другото, идеята на bvbfan съвсем не е лоша. Просто трябва да се имплементира потребителска функция за растоянието на Левенщайн в sqlite и директно да се напише заявка на SQL. Резултата може да се окаже съвсем изненадващо добър. ;-)



  |  Последно редактирано на 20.09.2020 от |, видяно: 1801 пъти. #11189
johnfound
|

Грешките може да са до над 100, но да предположим че ни интересува match с до 64 грешки.

Това какво значи? Че може да се дават като решение стрингове чието растояние на Левенщайн всъщност не е най-малкото в множество А?

Или че просто растоянието на Левенщайн трябва да се смята приблизително и някой път може да е грешно сметнато, но все пак е най-малкото сред грешно сметнатите?

Levenshtеin distance се смята между стрингове, които не съвпадат точно. Може да има до 100 такива разлики между стринговете. В общи линии, стринговете в колекция Б са грешни копия на стринговете е колекция А. Отделно му трябва и къде са грешките като позиция, както и какъв тип грешка е (insertion, deletion, substitution), но това са подробности и може да се сметне по-късно.

johnfound

Между другото, идеята на bvbfan съвсем не е лоша. Просто трябва да се имплементира потребителска функция за растоянието на Левенщайн в sqlite и директно да се напише заявка на SQL. Резултата може да се окаже съвсем изненадващо добър. ;-)

Наистина ли мислиш, че потребителска функция в sqlite ще е по-добра от в момента работещия мноконишков, сравнително оптимизиран код? :) Защото той отнема около седмица на машина с 48*2 ядра, при това когато стринговете от колекция А е 100К. :) А компютрите имат много памет, може да предположиш че е безкрайно много (1.5 TB).



  ФейкПрофил  Създадено на 20.09.2020, видяно: 1793 пъти. #11192

Някакви гени/днкта ли джуркаш ?



  |  Създадено на 20.09.2020, видяно: 1790 пъти. #11193
ФейкПрофил

Някакви гени/днкта ли джуркаш ?

Нещо такова, но по-просто.



  johnfound  Последно редактирано на 20.09.2020 от johnfound, видяно: 1783 пъти. #11198
|

Levenshtеin distance се смята между стрингове, които не съвпадат точно. Може да има до 100 такива разлики между стринговете. В общи линии, стринговете в колекция Б са грешни копия на стринговете е колекция А. Отделно му трябва и къде са грешките като позиция, както и какъв тип грешка е (insertion, deletion, substitution), но това са подробности и може да се сметне по-късно.

Тоест, си искал да кажеш че търсиш минималното разстояние, но не по-голямо от 100 (64). Понятието "грешка" в този контекст е заблуждаващо, още повече, че в предишното изречение използваш правилната дума "разстояние" в същият смисъл.

|

Наистина ли мислиш, че потребителска функция в sqlite ще е по-добра от в момента работещия мноконишков, сравнително оптимизиран код? :) Защото той отнема около седмица на машина с 48*2 ядра, при това когато стринговете от колекция А е 100К. :) А компютрите имат много памет, може да предположиш че е безкрайно много (1.5 TB).

Каква връзка имат нишките тука? SQLite също може да работи паралелно в много нишки, заявките могат ефективно да се разпаралелят, а SQLite има сериозно оптимизиран код, който със сигурност ще е по-бърз от това, което сте писали набързо.

Евентуално може да има проблеми само ако искате да изпълнявате на клъстър по мрежата, но и тогава може да се измисли нещо.



  |  Създадено на 20.09.2020, видяно: 1776 пъти. #11200
johnfound

Каква връзка имат нишките тука? SQLite също може да работи паралелно в много нишки, заявките могат ефективно да се разпаралелят, а SQLite има сериозно оптимизиран код, който със сигурност ще е по-бърз от това, което сте писали набързо.

И какво точно ще направи този "сериозно оптимизиран код" в sqlite? :) Можеш ли да го опишеш?



  johnfound  Последно редактирано на 21.09.2020 от code2, видяно: 1773 пъти. #11202

Между другото, специално в био-информатиката се смята за по-подходящо да се използва разстоянието на Дамерау-Левенщейн в което размяната на местата на два символа е една операция, а не 2.



  johnfound  Създадено на 20.09.2020, видяно: 1772 пъти. #11203
|

И какво точно ще направи този "сериозно оптимизиран код" в sqlite? :) Можеш ли да го опишеш?

В смисъл? Ще изпълнява SQL заявките, какво друго може да прави кода в SQL база данни?



  |  Създадено на 20.09.2020, видяно: 1769 пъти. #11205
johnfound

Между другото, специално в био-информатиката се смята за по-подходящо да се използва разстоянието на Дамерау-Левенщайн в което размяната на местата на два символа е една операция, а не 2.

Не и в този случай.



  |  Създадено на 20.09.2020, видяно: 1768 пъти. #11206
johnfound
|

И какво точно ще направи този "сериозно оптимизиран код" в sqlite? :) Можеш ли да го опишеш?

В смисъл? Ще изпълнява SQL заявките, какво друго може да прави кода в SQL база данни?

Как ТОЧНО ще изпълнява SQL заявките? Какви ще са заявките, и в какъв достъп до данните ще се транслират те?



  johnfound  Създадено на 20.09.2020, видяно: 1760 пъти. #11212
|

Как ТОЧНО ще изпълнява SQL заявките? Какви ще са заявките, и в какъв достъп до данните ще се транслират те?

Е, ти сега искаш да ти реша задачата на SQL ли?

Във всеки случай, бих започнал с нещо такова:

create table setA(strA text);
create table setB(strB text);

select 
  min(LsDist(strB, strA))
from
  setB left join setA
group by
  strB 

А по-нататък ще видя какво и как може да се оптимизира, раздели на нишки и т.н.



  |  Създадено на 20.09.2020, видяно: 1757 пъти. #11214
johnfound
|

Как ТОЧНО ще изпълнява SQL заявките? Какви ще са заявките, и в какъв достъп до данните ще се транслират те?

Е, ти сега искаш да ти реша задачата на SQL ли?

Във всеки случай, бих започнал с нещо такова:

create table setA(strA text);
create table setB(strB text);

select 
  min(LsDist(strB, strA))
from
  setB left join setA
group by
  strB 

А по-нататък ще видя какво и как може да се оптимизира, раздели на нишки и т.н.

И какви операции ще направи sqlite в този случай?



  johnfound  Създадено на 20.09.2020, видяно: 1754 пъти. #11216
|

И какви операции ще направи sqlite в този случай?

Ами пусни я и виж. Това си е твоя задача все пак.



  |  Последно редактирано на 20.09.2020 от |, видяно: 1752 пъти. #11218
johnfound
|

И какви операции ще направи sqlite в този случай?

Ами пусни я и виж. Това си е твоя задача все пак.

Няма нужда да го правя. Знам, че моят код е по-бърз. При това без да е оптимален.

П.П. Много е забавно когато някой фен на асемблера ми дава съвет да използвам sql за оптимален код. :)

П.П.2. Само една подсказка: това ВИНАГИ ще сравнява всяка двойка от стрингове.



  ФейкПрофил  Създадено на 20.09.2020, видяно: 1746 пъти. #11220

Тоест твоя код не прави всяко с всяко ?



  bvbfan  Създадено на 20.09.2020, видяно: 1746 пъти. #11221
|

Наистина ли мислиш, че потребителска функция в sqlite ще е по-добра от в момента работещия мноконишков, сравнително оптимизиран код? :) Защото той отнема около седмица на машина с 48*2 ядра, при това когато стринговете от колекция А е 100К. :) А компютрите имат много памет, може да предположиш че е безкрайно много (1.5 TB).

Ако питаш мен, аз не мисля, сигурен съм.



  |  Създадено на 20.09.2020, видяно: 1744 пъти. #11223
ФейкПрофил

Тоест твоя код не прави всяко с всяко ?

Не



  |  Създадено на 20.09.2020, видяно: 1742 пъти. #11225
bvbfan
|

Наистина ли мислиш, че потребителска функция в sqlite ще е по-добра от в момента работещия мноконишков, сравнително оптимизиран код? :) Защото той отнема около седмица на машина с 48*2 ядра, при това когато стринговете от колекция А е 100К. :) А компютрите имат много памет, може да предположиш че е безкрайно много (1.5 TB).

Ако питаш мен, аз не мисля, сигурен съм.

Е, като се има предвид, че беше сигурен че ARM използва gcc, OK. :)


0 1 2 3 4 ...17 18 19 20 21 ...32 33 34 35 36


Задача НЕ за интервю

  



AsmBB v3.0 (check-in: 7544654b24928b93); SQLite v3.47.0 (check-in: 03a9703e27c44437);
©2016..2024 John Found; Licensed under EUPL; Powered by Assembly language Created with Fresh IDE