<bgdev />free

Вход Регистрация

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

0 1 2 3 4 5 6 7 ....19 20 21 22 23 ....32 33 34 35 36
#11412 (ツ) bvbfan
Създадено на 21.09.2020, видяно: 1388 пъти.
|

Пак хехехехе. Johnfound е написал някакъв код в мнение 11212. Та, тази заявка ще извика ли потребителската функция за всяка двойка от стойности? Да или не?

Не е лоша заявката, това което е най-голямото предимство е, че оптимизираш заявката и може да добавиш индексиране и т.н. Това, което не може да направиш в твоят код е лесна оптимизация, защото говорим за комплексно решение.

#11413 (ツ) |
Последно редактирано на 21.09.2020 от |, видяно: 1386 пъти.
bvbfan
|

Пак хехехехе. Johnfound е написал някакъв код в мнение 11212. Та, тази заявка ще извика ли потребителската функция за всяка двойка от стойности? Да или не?

Не е лоша заявката, това което е най-голямото предимство е, че оптимизираш заявката и може да добавиш индексиране и т.н. Това, което не може да направиш в твоят код е лесна оптимизация, защото говорим за комплексно решение.

"Да" или "не"? Вика ли заявката функцията за разстояние за всеки две стойности?

Хайде бе хора, толкова ли е трудно да си признаеш, че си написал някоя идиотщина?

#11414 (ツ) ФейкПрофил
Последно редактирано на 21.09.2020 от ФейкПрофил, видяно: 1381 пъти.

може да добавиш индексиране 

Човек, всички бази данни ползват основно Б+дърво за индексите. С други думи индексите предствляват сортирана колекция в която може да търсиш със сложност O(log N), която е оптимизирана за бързо извличанена данни от диска. Как това помага за въпросния проблем ?

#11415 (ツ) bvbfan
Създадено на 21.09.2020, видяно: 1374 пъти.
|

OK, има ли решение на задачата в sqlite, което няма да сравни всеки две двойки стойности от таблиците? Да или не?

Разбира се, че има.

#11416 (ツ) bvbfan
Последно редактирано на 21.09.2020 от bvbfan, видяно: 1374 пъти.
ФейкПрофил

може да добавиш индексиране 

Човек, всички бази данни ползват основно Б+дърво за индексите. С други думи индексите предствляват сортирана колекция в която може да търсиш със сложност O(log N), която е оптимизирана за бързо извличанена данни от диска. Как това помага за въпросния проблем ?

Бързина? Това е цялата патагония, "неговият" код е по-бърз, да ама не.

#11418 (ツ) ФейкПрофил
Създадено на 21.09.2020, видяно: 1372 пъти.
bvbfan
ФейкПрофил

може да добавиш индексиране 

Човек, всички бази данни ползват основно Б+дърво за индексите. С други думи индексите предствляват сортирана колекция в която може да търсиш със сложност O(log N), която е оптимизирана за бързо извличанена данни от диска. Как това помага за въпросния проблем ?

Бързина? Това е цялата патагония, "неговият" код е по-бърз, да ама не.

От къде ще дойде тая бързинакато правиш всяко със всяко? Точно това ти обяснявам, че като правиш всяко със всяко е все тая дали са ти сортирани данните или не.

#11419 (ツ) |
Създадено на 21.09.2020, видяно: 1372 пъти.

И понеже един от другите "експерти" се чудеше как този код може да върви цяла седмица, си направих труда да препиша Levenshtein distance на C и да ИЗМЕРЯ (знам, шокиращо) колко време отнема смятането й за 1 стринг като първи аргумент и 100000 стринга като втори аргумент.

Отговорът е 2161 ms или 2.1 секунди.

Ако го изпълниш за 23 милиона стойности, това са 48300000 секунди или 13416 часа. Или 658 дни на един процесор.

#11420 (ツ) |
Създадено на 21.09.2020, видяно: 1370 пъти.
bvbfan
ФейкПрофил

може да добавиш индексиране 

Човек, всички бази данни ползват основно Б+дърво за индексите. С други думи индексите предствляват сортирана колекция в която може да търсиш със сложност O(log N), която е оптимизирана за бързо извличанена данни от диска. Как това помага за въпросния проблем ?

Бързина? Това е цялата патагония, "неговият" код е по-бърз, да ама не.

Все още очаквам да ми кажеш дали функцията ще се извика за всяка двойка от стойности. :)

Честно, много сте смешни с тези фантазии, че ако не признаете, че сте сгрешили, значи не сте сгрешили. :)

#11421 (ツ) |
Създадено на 21.09.2020, видяно: 1368 пъти.
bvbfan
|

OK, има ли решение на задачата в sqlite, което няма да сравни всеки две двойки стойности от таблиците? Да или не?

Разбира се, че има.

И какво е това решение? :)

#11422 (ツ) ФейкПрофил
Създадено на 21.09.2020, видяно: 1367 пъти.

А ползваш ли по-бърз алгритъм за смятане на edit distance-a ?

https://github.com/sunesimonsen/ukkonen

#11424 (ツ) bvbfan
Създадено на 21.09.2020, видяно: 1366 пъти.
|

Все още очаквам да ми кажеш дали функцията ще се извика за всяка двойка от стойности. :)

Честно, много сте смешни с тези фантазии, че ако не признаете, че сте сгрешили, значи не сте сгрешили. :)

Вече писах, че няма да се извика за всеки, явно не четеш. Не виждам, защо мислиш, че ние сме сгрешили, защото ползваме тестван софтуер и оптимизация отгоре, след като ти ползваш "твой" код, който да ми напишеш, че на Го било същото или по-бързо от С, само мога да ти кажа, че не можеш да пишеш на С.

#11425 (ツ) |
Създадено на 21.09.2020, видяно: 1366 пъти.
ФейкПрофил

А ползваш ли по-бърз алгритъм за смятане на edit distance-a ?

https://github.com/sunesimonsen/ukkonen

На младежа не му върши работа approximate. Мъчи се да прави error model на процеса на синтезис на ДНК като единствения резултат, който може да получи минава през няколко процеса (synthesis + multiple PCR cycles + sequencing) и всеки от тях добавя грешки. Не му е лесно. :)

#11426 (ツ) |
Създадено на 21.09.2020, видяно: 1365 пъти.
bvbfan
|

Все още очаквам да ми кажеш дали функцията ще се извика за всяка двойка от стойности. :)

Честно, много сте смешни с тези фантазии, че ако не признаете, че сте сгрешили, значи не сте сгрешили. :)

Вече писах, че няма да се извика за всеки, явно не четеш. Не виждам, защо мислиш, че ние сме сгрешили, защото ползваме тестван софтуер и оптимизация отгоре, след като ти ползваш "твой" код, който да ми напишеш, че на Го било същото или по-бързо от С, само мога да ти кажа, че не можеш да пишеш на С.

Не се опитвай да се измъкнеш измествайки темата. За кои двойки стойности няма да се извика?

#11427 (ツ) johnfound
Създадено на 21.09.2020, видяно: 1362 пъти.
|

"Да" или "не"? Вика ли заявката функцията за разстояние за всеки две стойности?

Хайде бе хора, толкова ли е трудно да си признаеш, че си написал някоя идиотщина?

Така, обяснявам като за начинаещи. Да, конкретната заявка, която цитираш вика функцията за разстояние за всеки две стойности.

Но! Да обявяваш с лека ръка такъв код за "идиотщина" е доста самоуверено от твоя страна. Начинаещите програмисти често са самоуверени, но да не се окаже, че ти си писал идиотщината, а да изчисляваш ефективно разстоянието е по-бързото решение.

Защото първо, твоят алгоритъм има абсолютно същата асимптотична сложност, като тривиалното решение с два вложени цикъла - О(m.n), където m и n са броят на елементите в съответните множества.

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

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

Второ, това, че точно тази заявка вика функцията за всяка двойка, съвсем не означава, че няма друга заявка, която да не вика функцията за всяка двойка стрингове. (И като имам предвид универсалността на SQL за обработка на данни, то такава заявка е по-вероятно да съществува, отколкото да не съществува.)

Именно затова и написах, че това е примерен код, от който да се започне разработката, а не на който да приключи.

#11428 (ツ) |
Последно редактирано на 21.09.2020 от |, видяно: 1358 пъти.
johnfound
|

"Да" или "не"? Вика ли заявката функцията за разстояние за всеки две стойности?

Хайде бе хора, толкова ли е трудно да си признаеш, че си написал някоя идиотщина?

Така, обяснявам като за начинаещи. Да, конкретната заявка, която цитираш вика функцията за разстояние за всеки две стойности.

Но! Да обявяваш с лека ръка такъв код за "идиотщина" е доста самоуверено от твоя страна. Начинаещите програмисти често са самоуверени, но да не се окаже, че ти си писал идиотщината, а да изчисляваш ефективно разстоянието е по-бързото решение.

Защото първо, твоят алгоритъм има абсолютно същата асимптотична сложност, като тривиалното решение с два вложени цикъла - О(m.n), където m и n са броят на елементите в съответните множества.

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

Хехехе, смешник, аз определено разбирам от програмиране МНОГО ПОВЕЧЕ от теб. :) Освен многото повече опит, имам и ДИПЛОМА доказваща го. :)

И аз, за разлика от теб имам доказателство, че trie e по-бързо. Защото го тествах вчера. Код с trie на Go e 1.5х по-бърз от НхМ сравнение на C.

Много са ми забавни екземпляри като теб и bvbfan, "ама то така", "ама то иначе". Ама да си признае "ей, верно бе, не се бях сетил за това" е НЕВЪЗМОЖНО. Винаги сте прави, нали? :)

#11429 (ツ) |
Последно редактирано на 21.09.2020 от |, видяно: 1355 пъти.
johnfound

Второ, това, че точно тази заявка вика функцията за всяка двойка, съвсем не означава, че няма друга заявка, която да не вика функцията за всяка двойка стрингове. (И като имам предвид универсалността на SQL за обработка на данни, то такава заявка е по-вероятно да съществува, отколкото да не съществува.)

"Blah-blah-blah универсиалността на товаааа, универсиалността на оновааа, вероятно е това да съществува, ама какво е това не е ясно". "Всичко е по-бързо на асемблер, ама никога не съм правил лууп ънролинг". Рабинщини. :)

Каква е тази заявка? Задачата е напълно дефинирана и елементарна.

#11430 (ツ) |
Създадено на 21.09.2020, видяно: 1350 пъти.

Да се чуди човек защо някой е измислял всички тези структури от данни и алгоритми след като просто можеха да използват sqlite. :)

#11432 (ツ) johnfound
Създадено на 21.09.2020, видяно: 1344 пъти.
|

Да се чуди човек защо някой е измислял всички тези структури от данни и алгоритми след като просто можеха да използват sqlite. :)

Ти обработваш данни. SQL въобще и SQLite в частност са създадени за обработка на данни. Не виждам какво странно има в идеята да използваш база данни за обработка на данни.

#11433 (ツ) |
Последно редактирано на 21.09.2020 от |, видяно: 1339 пъти.
johnfound
|

Да се чуди човек защо някой е измислял всички тези структури от данни и алгоритми след като просто можеха да използват sqlite. :)

Ти обработваш данни. SQL въобще и SQLite в частност са създадени за обработка на данни. Не виждам какво странно има в идеята да използваш база данни за обработка на данни.

Абсолютно всички програми обработват данни. Усещаш ли колко тъпо звучиш в момента само и само да не признаеш, че грешиш? :)

П.П. И друг път избягвай да ми казваш за какво имало надежда да стана, защото може да си мислиш че звучи арогантно, но от позицията в която съм в момента изглежда невероятно жалко. :)

#11434 (ツ) johnfound
Създадено на 21.09.2020, видяно: 1333 пъти.
|

"Всичко е по-бързо на асемблер, ама никога не съм правил лууп ънролинг".

Естествено, че всичко е по-бързо на асемблер. И разбира се, че съм правил (можеш ли да кажеш как е "loop unrolling" на български?)

И защо това е така, можеш да прочетеш ето тук: Why assembly programs are faster than HLL programs, despite that the compilers are so advanced?

0 1 2 3 4 5 6 7 ....19 20 21 22 23 ....32 33 34 35 36

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

AsmBB v3.0 (check-in: a316dab8b98d07d9); SQLite v3.42.0 (check-in: 831d0fb2836b71c9);
©2016..2023 John Found; Licensed under EUPL. Powered by Assembly language Created with Fresh IDE