Ale taką funkcję używam już w kodzie, w momencie kiedy pierwsza funkcja wbudowana zwróci odpowiednio niską punktację - wtedy używam dodatkowo tej z php obsługującej multibyte
No to chyba wszystko jest git, nie? I już po sprawie.
Chyba że masz ochotę jeszcze dalej próbować optymalizować swoje rozwiązanie, to ja proponuję użyć tego co napisał @katakrowa i zastąpić znaki diratyktyczne codepointami, to jest najprostsze a zarazem może dać znaczący wynik.
Tymczasem mając wbudowaną funkcję od razu w php mogę od razu dostać prawidłową punktację.
I byłoby to lepsze... czemu? Efekt w Twojej aplikacji i tak będzie taki sam.
Nie.
Po pierwsze nie muszę korygować punktacji levenshtaina zrobionej bez multibyte na tą z multibyte, żeby ją obniżyć i podwyższyć w rankingu propozycji - ale to mniejszy problem.
Większy problem jest kiedy w słowie są dwa lub więcej znaki diakrytyczne "spłaszczone" (np. a zamiast ą i e zamiast ę) i levenshtain bez multibyte zwraca tak wysoki wynik, że nawet nie uwzględnię tego w propozycjach, czyli mam np. 4 punktu zamiast 2, a próg propozycji to 3.
Mając od razu wbudowanego levenshteina z multibyte od razu mam 2 punkty i umieszczam to w propozycjach, a tak to mam do wyboru tracić takie propozycje albo podwyższyć próg punktacji levenshtaina dla uwzględnienia propozycji, co powoduje duże obniżenie wydajności, bo o wiele więcej muszę analizować / korygować funkcją w czystym PHP, która jest bardzo wolna.
Dlatego taka funkcja jest potrzebna tutaj.
Po drugie przecież wyraźnie napisałem tutaj i w readme, że potrzebuje to kolejnych optymalizacji: czyli zbudowania indeksu b-tree oraz rozłożenia na kilka wątków, a Ty tu wpisujesz rzeczy jakbyś w ogóle tego nie przeczytał. Zapętlasz się i w kółko piszesz to samo.
Przeczytałem, ale to wszystko jest bardzo odwrotne.
Stworzyłeś rozwiązanie które wykonuje się jakieś 5 minut, stwierdziłeś że za długo, i Twoim pomysłem było dodanie nowej funkcji do całego języka, a kolejnymi pomysłami było parallelizacja rozwiązania i model drzewa; ale nie wpadłeś na to żeby użyć już istniejącej funkcji żeby odsiać 99% słów z Twoich trzech milionów.
Nie, moje pierwsze rozwiązanie to była wbudowana funkcja, i działało to tak jak teraz 7 sek, potem spróbowałem to robić implementacją w PHP i zrobiło się kilka minut.
To będzie działać optymalnie kiedy:
- z prostego słownika w pliku linia po linii, zrobi się index b-tree i w ten sposób będzie się wykrywać nieistniejące słowa
- będzie wbudowana funkcja mb_levenshtein
- praca będzie mogła być podzielona na kilka wątków
Wtedy to będą ułamki sekund aby otrzymać propozycje dla tekstu który jest w teście na githubie, a nie 7 sekund jak teraz.
Po trzecie nie martw się tak bardzo petycją, dostałem już odpowiedź do deweloperów PHP że to dobry pomysł i będą implementować. No ale możesz tam napisać i się poskarżyć, że Tobie to bardzo przeszkadza, i żeby nie robili xD
No, z tego co widzę to dostałeś jedną odpowiedź od zwykłego użytkownika, oraz odpowiedź od @cmb69 że bez RFC nic nie zrobią.
Dobrze, ale napisał, że to dobry pomysł, i nie odrzucił tego.