Hasenhuf hat geschrieben:@ 800XE, ich zerbreche mir hier den Kopf aber verstehe das nicht. Ich glaube Du hast einiges weggelassen. Bevor ich mir sinnlos Gedanken mache ein paar Fragen:
Was ich weggelassen habe ist, woher bekomme ich die Treffer, wie ermittle ich sie .... wie lautet der SQLquery für #1 #2 #3
Ich habe eben "Armageddon" gesucht .... absichtlich falsch ohne "r"
"Amagedon" .... du siehst das ich hinten nur 1 d .... was auch falsch ist
deswegen fand #5 nichts, weil #4 nichts mehr zum Arbeiten hat
Amag != Armag
edon != eddon
midest eines der beiden müßte aber matchen um durch #4 durchzukommen .... also, aktuelle #4 ist Schrott
Hab Gedanklich schon was Anderes ....
gesuchehterString mit gefundenem Char by Char vergleichen und irgendwie vermerken wenn die Anzahl hintereinanderstehender unterschidlich ist oder in einem ein zusätzlicher drin ist ....
... geh ich jetzt in Richtung SoundEX .... neh, dort werden nehmlich vorhandene "gelöscht" sind unbeachtet ....
Hasenhuf hat geschrieben:1. Werden die Schritte 1 bis 4 immer alle ausgeführt und dann Schritt 5? Oder nur alle Schritte bis bei einem Schritt ein oder mehr Treffer gelandet werden und dann Schritt 5? Und wie ist Treffer definiert? Was machst Du mit den Wörtern, die die gleiche Buchstabenanzahl haben?
aktuell .... wenn #1 erfolgreich dann ende .... wenn User mehr will, gibts den zeiten [Button] um #2 #3 ... zu erzwingen ....
.... ja, aktuell wird immer alles gemacht
#3 ist aber unnötig weil nicht zur weiterverarbeitung genutzt
Gefundene Wörter von #1 und #2 gehen in die #4
https://webtools.chegu.de/meintestDu.ht ... n&domore=1
erzwungene weiterverarbeitung weil Armageddon richtig ist
#1 = meintest Du? (dreher) = findet 7 Wörter
#2 = meintest Du? (Char fehlt) = findet 50 Wörter
#3 .... wie gesagt .... nur da weil beim Test auch mal #2 nix lieferte ... derzeit keine Verwengung für die Ergebnisse
#4 ... 7 Wörter aus #1 und 50 aus #2 .... irgendwie schint ein Wort in beiden vorzukommen, welches durch #4 entvernt wird ..... bleiben 56 Wörter
57 »doubletten delete» 56
#4 zerhackt jetzt das Suchwort in der Mitte und metcht es mit den gefundenen ... vorderteil und hinterteil ... midestens einer muß stimmen
es bleiben 3
#5 die übriggeblibenen 3 Wörter, die werden jetzt in meinem AffiliateSuchindex abgefragt .... wie viele Suchtreffer gibt es dafür ...
domain.tld/?wortcount=Armageddon,Harmageddon,Wormageddon
77 mal
Armageddon
0 mal
Harmageddon
0 mal
Wormageddon
77max
READY....
hm, da hab ich jetzt ein Beispiel mit veralteten Artikeln ... = die Suchtreffer gibts nicht mehr = 0
unten als Abschluß kommt "Ready" und zufor die höchste Trefferzahl .... die nehm ich dann als 100%Marke ...... das kann so aber wohl nicht bleiben .....
.... auser die zukünftige #4 liefert besseres so das jetzige #5 so bleiben kann
Hasenhuf hat geschrieben:2. Wieso wird 'Andy' in #1 nicht gefunden in #3 aber schon? Findet außer dem Vergleich der Buchstabenzahl noch was anderes statt? Wenn ja, was?
#1 = meintest Du? (dreher) WHERE word_abcount = 4
#2 = meintest Du? (Char fehlt) WHERE word_abcount = 5
word_abccount .... wortlänge .... abc count (c doppelverwendet .. abc + count)
word_abcount = der strlen von meinem alpaorderet
andy .... = adny = 4
andi .... = adni = 4
Tastatur = arstu = 5
aber, wie gesagt, das adny oder adni wird nicht weiterverwendet ....
... ist ein Nebenprodukt vom füllen der SQL
Code: Alles auswählen
$alpha= strtolower( $query );
// bei mir hl2fn = headline2filename
// = Ümlate in ue ae oe umwandlung mit drin
$i=ord('a')-1;
$alphas=0;
while($i++<ord('z'))
{
$c=chr($i);
if ( strpos(' '.$alpha,$c) )
{
// gefundene Chars in einen SQL WHERE ....
$alphas++;
}
}
armageddon hat als $alphas==8
obwohl strlen( armageddon )==10
wieder zum andy vs andy
#1 = meintest Du? (dreher) WHERE word_abcount = 4
Wörter die im alphaORDERETstr so lange sind wie das gesuchte Wort
········ WHERE $alphas==4 && die Chars A+n+d+y ....
#2 = meintest Du? (Char fehlt) WHERE word_abcount = 5
Wörter die im alphaORDERETstr
ein zeichen länger wie das gesuchte Wort
········ WHERE $alphas==5 && die Chars A+n+d+y ....
falsch Andy wird in #2 nicht gefunden .... in #3 wird es gefunden ....
in #3 gilt wieder
$alphas==gesucht wie gefunden .... aber das Charmatch ist nicht so strickt
von den 4 müßen nur 3 stimmen
aber die #3 ist nicht gut wie sie jetzt ist .... braucht zu viel Rechenzeit
für Andi vs Andy sollte ich doch mal soundex .....
.... beide A530 .... rückwerts i350 bzw y350 ....
Andreas = A536 .... nahe an A530 ..... hm .....
mal schauen ....
... die #3 dahingehend ändern das sie wie die #2 aber eben mehrfach, immer mir einem Buchstaben zu wenig um sich dann eventuell mit einem vertipperChar zu korekturErgenzen ....
.... und dann, oder schon vorher, einen soundex abmatchen
Hasenhuf hat geschrieben:800XE hat geschrieben:Der "Schar" der "Arsch" ....
.... sind nicht ähnlich, mathematisch sind sie exakt gleich
5Buchstaben
1xA
1xC
1xH
1xS
1xR
Da Du weißt, daß dein Algo keine Gleichheit von Wörtern bestimmen kann, dachte ich, Du würdest die exakte Übereinstimmung deines "Hashes" lediglich als höchste Ähnlichkeit ansehen.
schub und Busch ...... da haben wir noch so zwei
für meinen Algo, wenn man das so nennen kann,
sind die zwei Wörter erstmal absolut identisch
also, für #1 #2 #3 .... = SQL abfrage
#4 ist dann PHP mit einem strcmp
ich glaub ich schau mir doch mal soundex an
...
