0 1 2 3 4 5 6 7 ...19 20 21 22 23 ...32 33 34 35 36
Не е лоша заявката, това което е най-голямото предимство е, че оптимизираш заявката и може да добавиш индексиране и т.н. Това, което не може да направиш в твоят код е лесна оптимизация, защото говорим за комплексно решение.
"Да" или "не"? Вика ли заявката функцията за разстояние за всеки две стойности?
Хайде бе хора, толкова ли е трудно да си признаеш, че си написал някоя идиотщина?
може да добавиш индексиране
Човек, всички бази данни ползват основно Б+дърво за индексите. С други думи индексите предствляват сортирана колекция в която може да търсиш със сложност O(log N), която е оптимизирана за бързо извличанена данни от диска. Как това помага за въпросния проблем ?
Бързина? Това е цялата патагония, "неговият" код е по-бърз, да ама не.
От къде ще дойде тая бързинакато правиш всяко със всяко? Точно това ти обяснявам, че като правиш всяко със всяко е все тая дали са ти сортирани данните или не.
И понеже един от другите "експерти" се чудеше как този код може да върви цяла седмица, си направих труда да препиша Levenshtein distance на C и да ИЗМЕРЯ (знам, шокиращо) колко време отнема смятането й за 1 стринг като първи аргумент и 100000 стринга като втори аргумент.
Отговорът е 2161 ms или 2.1 секунди.
Ако го изпълниш за 23 милиона стойности, това са 48300000 секунди или 13416 часа. Или 658 дни на един процесор.
Все още очаквам да ми кажеш дали функцията ще се извика за всяка двойка от стойности. :)
Честно, много сте смешни с тези фантазии, че ако не признаете, че сте сгрешили, значи не сте сгрешили. :)
А ползваш ли по-бърз алгритъм за смятане на edit distance-a ?
https://github.com/sunesimonsen/ukkonen
Вече писах, че няма да се извика за всеки, явно не четеш. Не виждам, защо мислиш, че ние сме сгрешили, защото ползваме тестван софтуер и оптимизация отгоре, след като ти ползваш "твой" код, който да ми напишеш, че на Го било същото или по-бързо от С, само мога да ти кажа, че не можеш да пишеш на С.
На младежа не му върши работа approximate. Мъчи се да прави error model на процеса на синтезис на ДНК като единствения резултат, който може да получи минава през няколко процеса (synthesis + multiple PCR cycles + sequencing) и всеки от тях добавя грешки. Не му е лесно. :)
Не се опитвай да се измъкнеш измествайки темата. За кои двойки стойности няма да се извика?
Така, обяснявам като за начинаещи. Да, конкретната заявка, която цитираш вика функцията за разстояние за всеки две стойности.
Но! Да обявяваш с лека ръка такъв код за "идиотщина" е доста самоуверено от твоя страна. Начинаещите програмисти често са самоуверени, но да не се окаже, че ти си писал идиотщината, а да изчисляваш ефективно разстоянието е по-бързото решение.
Защото първо, твоят алгоритъм има абсолютно същата асимптотична сложност, като тривиалното решение с два вложени цикъла - О(m.n), където m и n са броят на елементите в съответните множества.
Това, което ти печелиш със използването на trie структура, е ускоряване на изчисленията на разстоянието, но дали това ускоряване ще покрие всички забавяния, които правиш за да го използваш, е момент, който следва да се докаже.
(Ако си прочел до тука и си разбрал за какво говоря, има някаква надежда, че от теб някога ще стане програмист. Продължавай да четеш нататък)
Второ, това, че точно тази заявка вика функцията за всяка двойка, съвсем не означава, че няма друга заявка, която да не вика функцията за всяка двойка стрингове. (И като имам предвид универсалността на SQL за обработка на данни, то такава заявка е по-вероятно да съществува, отколкото да не съществува.)
Именно затова и написах, че това е примерен код, от който да се започне разработката, а не на който да приключи.
Хехехе, смешник, аз определено разбирам от програмиране МНОГО ПОВЕЧЕ от теб. :) Освен многото повече опит, имам и ДИПЛОМА доказваща го. :)
И аз, за разлика от теб имам доказателство, че trie e по-бързо. Защото го тествах вчера. Код с trie на Go e 1.5х по-бърз от НхМ сравнение на C.
Много са ми забавни екземпляри като теб и bvbfan, "ама то така", "ама то иначе". Ама да си признае "ей, верно бе, не се бях сетил за това" е НЕВЪЗМОЖНО. Винаги сте прави, нали? :)
"Blah-blah-blah универсиалността на товаааа, универсиалността на оновааа, вероятно е това да съществува, ама какво е това не е ясно". "Всичко е по-бързо на асемблер, ама никога не съм правил лууп ънролинг". Рабинщини. :)
Каква е тази заявка? Задачата е напълно дефинирана и елементарна.
Да се чуди човек защо някой е измислял всички тези структури от данни и алгоритми след като просто можеха да използват sqlite. :)
Ти обработваш данни. SQL въобще и SQLite в частност са създадени за обработка на данни. Не виждам какво странно има в идеята да използваш база данни за обработка на данни.
Абсолютно всички програми обработват данни. Усещаш ли колко тъпо звучиш в момента само и само да не признаеш, че грешиш? :)
П.П. И друг път избягвай да ми казваш за какво имало надежда да стана, защото може да си мислиш че звучи арогантно, но от позицията в която съм в момента изглежда невероятно жалко. :)
Естествено, че всичко е по-бързо на асемблер. И разбира се, че съм правил (можеш ли да кажеш как е "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