nicht angemeldetHallo,
mich nervt es immer wieder, dass bei der Archivsuche das Kästchen "Groß- bzw. Kleinschreibung berücksichtigen" standardmäßig aktiviert ist. Kann das mal jemand ausstellen?
Es ist einfach lästig, wenn ich immer wieder Fingerspitzengefühl aufwenden muss, um den Cursor mittels meines Touchpads (und ich hasse Touchpads) auf diesem Kästchen zu positioneren. Nicht dass ich mir für feinste Fingerbewegungen zu schade wäre, aber dieser unnötige Energieaufwand wäre doch durch eine kleine HTML-Veränderung im Nu aus der Welt geschaffen.
Ich meine, welcher Mensch (abgesehen von meiner Mutter) gibt denn Suchanfragen im Internet in korrekter Groß-/Kleinschreibung ein? Und wenn schon, es ist ja nicht sicher, dass genau das gesuchte Posting die korrekte Groß-/Kleinschreibung einhält.
Michel
PS: Meinetwegen könnten indes die Forums-Archive 2001 - 2004 standardmäßig aktiviert werden. (Wobei es aber wahrscheinlich überlastungstechnische Gründe hat, dass diese Optionen bis dato gerade nicht aktiviert sind)
Hallo auch von mir,
jepp das stimmt das Groß und klein schreibe das ist echt nervig. Man könnte das doch so programmieren, dass das egal ist ob groß oder klein denn wie auch vorhin schon gesagt woher soll ich wissen was vor 8 WOchen mal geschrieben worden ist also Groß oder Klein hmmm da sollte man wirklich mal was machen.
Gruß Jasmin
Hi,
Man könnte das doch so programmieren, dass das egal ist ob groß oder klein [...]
das, was hier thematisiert wird, ist in der Konsequenz die Forderung nach einem Funktionalitaetsabbau. - Vielleicht sollte man sich doch eher auf die Frage nach der "richtigen" Defaulteinstellung konzentrieren? Oder auf die Frage, ob nicht bereits alles fuer "eingeloggte Nutzer" konfigurierbar ist bzw. konfigurierbar gemacht werden sollte?
Gruss,
Ludger
Hi,
Es ist einfach lästig, wenn ich immer wieder Fingerspitzengefühl aufwenden muss, um den Cursor mittels meines Touchpads (und ich hasse Touchpads) auf diesem Kästchen zu positioneren.
Wenn Du Touchpads haßt, warum benutzt Du sie dann?
Die Tab-Taste funktioniert, die Leerzeichentaste auch ...
PS: Meinetwegen könnten indes die Forums-Archive 2001 - 2004 standardmäßig aktiviert werden. (Wobei es aber wahrscheinlich überlastungstechnische Gründe hat, dass diese Optionen bis dato gerade nicht aktiviert sind)
Hm - hier hast Du Verständnis für die "überlastungstechnischen Gründe".
mich nervt es immer wieder, dass bei der Archivsuche das Kästchen "Groß- bzw. Kleinschreibung berücksichtigen" standardmäßig aktiviert ist. Kann das mal jemand ausstellen?
Hier hast Du aber kein Verständnis für die "überlastungstechnischen Gründe".
Eine case-insensitive Suche ist nun mal aufwendiger.
cu,
Andreas
Hi,
Eine case-insensitive Suche ist nun mal aufwendiger.
ich stelle mir das so vor, dass ein Volltextindex auf dem Archiv und auf den anderen Ressourcen liegt. Dann saehe ich keinen zusaetzlichen Aufwand, sofern der Index OK ist, oder?
Oder wird hier etwa "just in time" gesucht? ;-)
Gruss,
Ludger
你好 Ludger,
Eine case-insensitive Suche ist nun mal aufwendiger.
ich stelle mir das so vor, dass ein Volltextindex auf dem Archiv und auf
den anderen Ressourcen liegt. Dann saehe ich keinen zusaetzlichen
Aufwand, sofern der Index OK ist, oder?
Selbstverstaendlich ist eine case-insensitive Suche immer aufwendiger als
eine Case-sensitive. Mach doch mal eine Aufwandsanalyse fuer beide Faelle.
再见,
CK
Hi,
Eine case-insensitive Suche ist nun mal aufwendiger.
ich stelle mir das so vor, dass ein Volltextindex auf dem Archiv und auf
den anderen Ressourcen liegt. Dann saehe ich keinen zusaetzlichen
Aufwand, sofern der Index OK ist, oder?Selbstverstaendlich ist eine case-insensitive Suche immer aufwendiger als
eine Case-sensitive. Mach doch mal eine Aufwandsanalyse fuer beide Faelle.
ein Index beinhaltet so zu sagen antizipierte Abfragen. Insofern waere die Komplexitaet der Abfrage vom Aufwand losgeloest zu betrachten.
der Vollstaendigkeit halber die kleinen Einschraenkungen zur o.gemachten Aussage:
a) den Aufwand fuer die Indexerstellung lassen wir unbetrachtet
b) die Indexgroesse und die moeglicherweise etwas aufwendigere Suche im Index lassen wir unbetrachtet
Gruss,
Ludger
Hallo Ludger,
vorneweg: es läuft noch die alte Suche.
ich stelle mir das so vor, dass ein Volltextindex auf dem Archiv und auf den anderen Ressourcen liegt. Dann saehe ich keinen zusaetzlichen Aufwand, sofern der Index OK ist, oder?
Da liegst Du allerdings falsch. Der Index bei der alten Suche ist nichts anderes als eine Riesen-Textdatei, die in jeder Zeile den Inhalt genau eines Postings enthält sowie zusätzliche Informationen (Postingid, Autor, etc.). Diese Textdatei muss von der alten Suche _komplett_ durchsucht werden. Wenn man dann auch noch "case insensitive" aktiviert, dauert das ganze nochmal deutlich länger.
Viele Grüße,
Christian
你好 Christian,
ich stelle mir das so vor, dass ein Volltextindex auf dem Archiv und
auf den anderen Ressourcen liegt. Dann saehe ich keinen zusaetzlichen
Aufwand, sofern der Index OK ist, oder?Da liegst Du allerdings falsch. Der Index bei der alten Suche ist
nichts anderes als eine Riesen-Textdatei, die in jeder Zeile den
Inhalt genau eines Postings enthält sowie zusätzliche Informationen
(Postingid, Autor, etc.).
Das ist das, was man langlaeufig als “Volltextindex” bezeichnet ;-)
再见,
CK
Hi,
Da liegst Du allerdings falsch. Der Index bei der alten Suche ist nichts anderes als eine Riesen-Textdatei,
so zusagen ein Voll-Voll-Index, huestl.
Gruss,
Ludger
Hi
Da liegst Du allerdings falsch. Der Index bei der alten Suche ist nichts anderes als eine Riesen-Textdatei, die in jeder Zeile den Inhalt genau eines Postings enthält sowie zusätzliche Informationen (Postingid, Autor, etc.). Diese Textdatei muss von der alten Suche _komplett_ durchsucht werden.
Mal ne technische Diskussion, ohne Kritik üben zu wollen: Wollte man alle Features beibehalten und trotzdem den Aufwand zu minimieren trachten, dann wäre eine zweistufige Suche besser:
1. eine Indexdatei auf Basis kleingeschriebener Wörter (ohne Stoppwörter).
2. ausfiltern der (m.E wenigen) inkorrekten Treffer.
die riesige Volltextdatei könnte man einsparen, wenn Schritt 2 direkt im Archiv läuft, und dabei gleich einige Unschönheiten korrigieren (im Preview sind Zitate nicht kenntlich/ausblendbar, was zu irritierenden Wiederholungen führt, Sonerzeichen kommen falsch rüber)
Da ich sowieso demnächst eine sehr ähnliche Suchmaschine realisieren muss, wärs interessant zu wissen ob noch an der neuen SQL-Lösung gearbeitet wird.
Michaels Vorschlag in Richtung FDSE (?) gilt es natürlich auch zu erwägen.
Tschau
Rolf
Hallo Rofl,
- eine Indexdatei auf Basis kleingeschriebener Wörter (ohne Stoppwörter).
- ausfiltern der (m.E wenigen) inkorrekten Treffer.
Naja, so ähnlich ist ja die neue Suche geplant, nur halt in einer Datenbank und nicht mit einer Datei. Ok, Dateien sind auch beteiligt, frag doch einfach Daniela, wie das geanu funktioniert. ;-)
Da ich sowieso demnächst eine sehr ähnliche Suchmaschine realisieren muss, wärs interessant zu wissen ob noch an der neuen SQL-Lösung gearbeitet wird.
Die neue SQL-Lösung ist eigentlich fertig, es wird im Moment nur mit hardwaretechnischen Problemen gekämpft (der Plattenplatz reicht für den Index in der Datenbank nicht aus).
Viele Grüße,
Christian
Hi Christain
Die neue SQL-Lösung ist eigentlich fertig, es wird im Moment nur mit hardwaretechnischen Problemen gekämpft (der Plattenplatz reicht für den Index in der Datenbank nicht aus).
Ich hab ja nie eine DB administrieren wollen, aber der Index schluckt mehr Platz als die Schroeplsche Volltextdatei???
Viele Grüße,
Rolf
你好 LanX!,
Die neue SQL-Lösung ist eigentlich fertig, es wird im Moment nur mit
hardwaretechnischen Problemen gekämpft (der Plattenplatz reicht für den
Index in der Datenbank nicht aus).Ich hab ja nie eine DB administrieren wollen, aber der Index schluckt
mehr Platz als die Schroeplsche Volltextdatei???
Ist doch auf voellig logisch. Es fallen viel mehr Metadaten an.
再见,
CK
Hi CK
mehr Platz als die Schroeplsche Volltextdatei???
Ist doch auf voellig logisch. Es fallen viel mehr Metadaten an.
Ähm, eigentlich nicht wenn man zweistufig arbeitet...Ihr habt aber wohl ein anderes Konzept.
Was sind hier Metadaten? Speichert ihr zu jedem _Wort_ Autor, Datum, Link, etc als Strings ab? Es reicht doch eine Referenz aufs Postinginfos in einer Tabelle abzulegen, soviel Zeit kostet das doch wohl nicht.
Ich hab jetzt keine Zeit es durchzurechnen (Party ruft) aber ich fürchte ihr arbeitet etwas uneffektiv.
etwas Mathe...
Es reicht eine Matrix (Postings x Wörter) zu betrachten, und überall ne 1 zu setzen, wo was vorkommt.
Michaels Index listet über die Postings alle Wörter auf (mit Wiederholungen in richtiger Reihenfolge).
Mein Wortindex ginge über die andere Achse und listet die Postings auf die das jeweilige Wort beinhalten.
Prinzip der doppelten Abzählung: Beide Indizes haben gleich viele Einträge resp. 1en (mit Wortwiederholung braucht Michaels Methode sogar noch mehr), da aber Referenzen² im Schnitt kürzer sind als Wörter in ASCII/UNICODE, braucht der 2 Index aber _weniger_ Platz.
Man könnte die Sache noch weitertreiben und mit einem Stämmer arbeiten um die Anzahl der Wörter zu verkleinern. (suchen, suche, suchte = such)
Ob die Wörter im Posting dann mit der richtigen Endungen, Reihenfolge Stoppwörter oder RegExp auftauchen läßt sich im 2 Suchschritt dann wieder bequem im Archiv überprüfen.
Den einzigen Flaschenhals sähe ich bei den Filesystemzugriffen ins Archiv für den 2 Schritt, da würd ich aber die maximale Trefferzahl der suche beschränken, denn wer ernsthaft mehr als 50 Treffer haben will, ist zu faul die Suche zu verfeinern.
Versucht Michaels Script eigentlich den Vollindex im Speicher zu halten, und wenn ja wieviel RAM hat der Server?
Bis nächstes Jahr :)
rolf
²4 Bytes reichen für 2^32 Postings.
Hi,
was macht ihr eigentlich alle noch hier? Keine Einladung? ;-)
(Bevor jemand dumme Fragen stellt: ich sollte ein Roastbeef machen, das muß noch etwas Zeit im Ofen verbringen. Dann bin ich auch weg.)
mehr Platz als die Schroeplsche Volltextdatei???
Ist doch auf voellig logisch. Es fallen viel mehr Metadaten an.
Ähm, eigentlich nicht wenn man zweistufig arbeitet...Ihr habt aber wohl ein anderes Konzept.
Was sind hier Metadaten? Speichert ihr zu jedem _Wort_ Autor, Datum, Link, etc als Strings ab? Es reicht doch eine Referenz aufs Postinginfos in einer Tabelle abzulegen, soviel Zeit kostet das doch wohl nicht.
Aber Raum und das ist die Absicht. Hier wird der übliche Handel getrieben: Platz gegen Geschwindigkeit. Nur reicht jetzt dummerweise der Raum nicht und das DB-Konzept muß geändert werden. Das man da erstmal keine Lust mehr hat, wenn man das feststellt finde ich durchaus verständlich ;-)
Aber nebenbei: selbst so ein einfacher Index, wie er Dir vorschwebt verbrät ordentlich Platz:
Gesetzt den Fall, das nach Abzug aller Stopwörter und sonstigem Mist alle Wörter (= mit Leerzeichen/Newline getrennte Buchstabenanhäufungen) niedergemacht (lowercase()) werden, kommen da bestimmt so um die 100.000 Worte zusammen. Alle komprimiert (32Bit reicht da völlig) und mit einem Pointer (auch mal von 32Bit ausgegangen) auf die eigentlichen Metadaten versehen macht das 800.000 Oktets. Overhead der Hashtable/des Baumes gar nicht mitgerechnet.
Also alleine schon ein knappes Gig für die platzsparendste(!) Lösung! Was da bei einer auch nur _etwas_ mehr auf Geschwindigkeit ausgelegter Lösung zusammenkommt muß ich ja hier nicht mehr vorrechnen, oder? ;-)
Dazu ist der Komfort des oben beschriebenen Primitivstindexes nicht sehr sonderlich, da würden sich mit Sicherheit alle beschweren.
so short
Christoph Zurnieden
Hi Christoph
Aber Raum und das ist die Absicht. Hier wird der übliche Handel getrieben: Platz gegen Geschwindigkeit. Nur reicht jetzt dummerweise der Raum nicht und das DB-Konzept muß geändert werden. Das man da erstmal keine Lust mehr hat, wenn man das feststellt finde ich durchaus verständlich ;-)
Schön wäre es, aber es lässt sich nicht wirklich Platz sparen, die Datenbank selber ist ja klein genug um auf die HD zu passen (etwa 6 od 7 GB waren es), nur soll die geclustert werden, also physische Sortierung = meistgebrauchter Sortierung, für den Sortiervorgang braucht es aber wegen ACID und so mal eben gut das doppelte an Speicherplatz. Bei diesem Vorgang hats dann Bumm gemacht, der Index wäre komplett fertig gewesen. *ärger*
Deswegen sollte Heimdall jetzt endlich mal ankommen und etwas ausgebaut werden. Alles schon geplant, es fehlt aktuell nur daran, das der einfach nicht verschickt wird...
Gruss Daniela
Hi,
Schön wäre es, aber es lässt sich nicht wirklich Platz sparen, die Datenbank selber ist ja klein genug um auf die HD zu passen (etwa 6 od 7 GB waren es), nur soll die geclustert werden, also physische Sortierung = meistgebrauchter Sortierung, für den Sortiervorgang braucht es aber wegen ACID und so mal eben gut das doppelte an Speicherplatz. Bei diesem Vorgang hats dann Bumm gemacht, der Index wäre komplett fertig gewesen. *ärger*
Auha, das ist dann aber wirklich unangenehm.
Vorsichtig ausgedrückt ;-)
BTW: Wo hast Du eigentlich Deinen Sedgewick, die "Algorithms"? Schlag doch mal Kapitel 13 auf ... >;->
Deswegen sollte Heimdall jetzt endlich mal ankommen und etwas ausgebaut werden. Alles schon geplant, es fehlt aktuell nur daran, das der einfach nicht verschickt wird...
Aber es ist doch immer wieder schön, wenn's andere Schuld sind, oder? ;-)
so short
Christoph Zurnieden
Hi Christoph
Schön wäre es, aber es lässt sich nicht wirklich
Auha, das ist dann aber wirklich unangenehm.
Vorsichtig ausgedrückt ;-)BTW: Wo hast Du eigentlich Deinen Sedgewick, die "Algorithms"? Schlag doch mal Kapitel 13 auf ... >;->
Theoretisch möglich, ist aber mühsam wenn dann mittendrin etwas passiert und ich dann die Hälfte der Daten in der alten Tabelle und die Hälfte in der neuen habe. Deswegen macht das DBMS es ja nicht auf diese Art.
Ausserdem hilft das auch nicht auf Dauer, die Datenmenge wird ja auch laufend mehr und die Suche ist nicht die einzige Datenbank auf dem Server.
Aber es ist doch immer wieder schön, wenn's andere Schuld sind, oder? ;-)
Schuld das es Probleme gab nicht, aber der Rechner steht inzwischen seit mehr als einem Monat da und müsste nur mal verschickt werden um ihn wieder flott zu machen, vorher stand er auch ein halbes Jahr noch beim Provider... Der soll jetzt seit nem 3/4 Jahr wieder zum Einsatz kommen.
Gruss Daniela
Hi,
BTW: Wo hast Du eigentlich Deinen Sedgewick, die "Algorithms"? Schlag doch mal Kapitel 13 auf ... >;->
Theoretisch möglich, ist aber mühsam wenn dann mittendrin etwas passiert und ich dann die Hälfte der Daten in der alten Tabelle und die Hälfte in der neuen habe.
Wenn geschickt gemacht, kannst Du aus beiden Hälften wieder ein Ganzes zusammenbauen. Oder gleich in-place sortieren (was dann aber wieder andere Schwierigkeiten aufwirft) oder verteilt (was dann zwar interessant wäre, aber nun wirklich zu komplex, um das "mal eben" zu machen).
Aber war ja nicht wirklich ernstgemeint mein Vorschlag, nur ein Hinweis darauf, das es zur Not auch funktionieren würde. Hatte ja nicht nur wegen des Schönheit ein "devils grin mit Hörnchen" hintendran gemalt.
Deswegen macht das DBMS es ja nicht auf diese Art.
Die machen das, weil es einfach und sicher ist. Beides normalerweise hervorragende Argumente. Nur wenn dann mal der Platz dafür nicht reicht, ist man halt - nun, wie kann ich's höflicher sagen: angeschissen.
Und wenn dann auch noch die Dienstleister und Lieferanten nicht mitspielen ist's eh Essig.
Aber es ist doch immer wieder schön, wenn's andere Schuld sind, oder? ;-)
Schuld das es Probleme gab nicht, aber der Rechner steht inzwischen seit mehr als einem Monat da und müsste nur mal verschickt werden um ihn wieder flott zu machen, vorher stand er auch ein halbes Jahr noch beim Provider... Der soll jetzt seit nem 3/4 Jahr wieder zum Einsatz kommen.
Ein Dreivierteljahr? Gab es denn gar keine Möglichkeit den Leuten in den Hintern zu treten? Und jetzt wird's eh noch etwas länger dauern, denn vor Mitte Januar ist wahrscheinlich auch nichts zu machen. Kenn' die Brüder: wenn Du da nicht persönlich erscheinst und Rabatz schlägst passiert rein gar nichts. Mitunter auch trotz. Oder weil? ;-)
(Ist aber auch sowieso zu weit weg, oder?)
so short
Christoph Zurnieden
Hi Christoph,
Aber nebenbei: selbst so ein einfacher Index, wie er Dir vorschwebt verbrät ordentlich Platz:
Gesetzt den Fall, das nach Abzug aller Stopwörter und sonstigem Mist alle Wörter (= mit Leerzeichen/Newline getrennte Buchstabenanhäufungen) niedergemacht (lowercase()) werden, kommen da bestimmt so um die 100.000 Worte zusammen. Alle komprimiert (32Bit reicht da völlig) und mit einem Pointer (auch mal von 32Bit ausgegangen) auf die eigentlichen Metadaten versehen macht das 800.000 Oktets. Overhead der Hashtable/des Baumes gar nicht mitgerechnet.
soweit korrekt.
Also alleine schon ein knappes Gig für die platzsparendste(!) Lösung!
ein knappes MB :) Oder scklucken deine Oktets 1KB?
Ich schätze 10-100MB maximal mit Sonderfeatures.
Was da bei einer auch nur _etwas_ mehr auf Geschwindigkeit ausgelegter Lösung zusammenkommt muß ich ja hier nicht mehr vorrechnen, oder? ;-)
Ich denke Hashtabllen sind ziemlich unschlagbar.
Dazu ist der Komfort des oben beschriebenen Primitivstindexes nicht sehr sonderlich, da würden sich mit Sicherheit alle beschweren.
der deckt aber m.E. 90% aller Abfragen ab, für den Rest braucht es noch den 2. Suchschritt zum Ausfiltern. (schätze weitere 9% suchen nach Phrasen wie "meines Erachtens")
so short
even shorter ;)
rolf
PS: Eins hab ich noch außer acht gelassen: Ich habe vereinfacht angenommen an suche ganze Wörter. Man bräuchte noch eine vorgeschaltete Suche die ermittelt in welchen Stichwörtern beliebige Teilwörter vorkommen. Sowas lässt sich nur schlecht "verhashen", da wäre ne DB wohl stärker...
你好 LanX!,
Was da bei einer auch nur _etwas_ mehr auf Geschwindigkeit
ausgelegter Lösung zusammenkommt muß ich ja hier nicht mehr
vorrechnen, oder? ;-)Ich denke Hashtabllen sind ziemlich unschlagbar.
Hash-Tabellen sind bei grossen Datenmengen recht unbrauchbar, weil es zu
viele Dubletten gibt. Je mehr Daten auf einen begrenzten Raum abgebildet
werden muessen, desto mehr Dubletten gibt es.
再见,
CK
Hi
Hash-Tabellen sind bei grossen Datenmengen recht unbrauchbar, weil es zu
viele Dubletten gibt. Je mehr Daten auf einen begrenzten Raum abgebildet
werden muessen, desto mehr Dubletten gibt es.
Dahingehend kann man Hashes auch parametrisieren, oder?
Bye
rolf
你好 LanX!,
Hash-Tabellen sind bei grossen Datenmengen recht unbrauchbar, weil es zu
viele Dubletten gibt. Je mehr Daten auf einen begrenzten Raum abgebildet
werden muessen, desto mehr Dubletten gibt es.Dahingehend kann man Hashes auch parametrisieren, oder?
Nicht wirklich. Es liegt in der Natur von Hash-Tabellen, dass sie dieses
Problem haben; ab einer bestimmten Groesse sind sie einfach ineffizient,
da halt die Tabelle nur eine bestimmte Groesse hat (haben kann).
再见,
CK
Hi CK,
da halt die Tabelle nur eine bestimmte Groesse hat (haben kann).
Wieso? Was hält mich davon ab eine eigene Hashfunktion zu schreiben und auf ein Array zuzugreifen?
Tschau
rolf
你好 LanX!,
da halt die Tabelle nur eine bestimmte Groesse hat (haben kann).
Wieso? Was hält mich davon ab eine eigene Hashfunktion zu schreiben und
auf ein Array zuzugreifen?
Die Hash-Funktion hat immer einen bestimmten Wertebereich. Du kannst die
Tabelle schliesslich nicht beliebig gross machen. Irgendwann wird dadurch
aber auch diese Tabelle zu klein. Bei (theoretisch) unbegrenzt vielen Daten
ist eine Hash-Tabelle einfach nicht das wahre, akzeptiere das doch
einfach ;-)
再见,
CK
Hi
Die Hash-Funktion hat immer einen bestimmten Wertebereich. Du kannst die
Tabelle schliesslich nicht beliebig gross machen. Irgendwann wird dadurch
aber auch diese Tabelle zu klein. Bei (theoretisch) unbegrenzt vielen Daten
ist eine Hash-Tabelle einfach nicht das wahre, akzeptiere das doch
einfach ;-)
Die Daten sind aber 1. nicht unbegrenzt weil wir nur ein begrenztes Vokabular haben (Selfdeutsch und deine "??" ;), ausserdem gehst du glaube ich von einem geschlossenen Hash aus, ich aber von einem offenen.
Was spricht also dagegen als Hashwert wiederum einen weiteren Hash zu haben, der alle möglichen Kollisionen beinhaltet?
Bye bye
rolf
你好 LanX²,
Die Hash-Funktion hat immer einen bestimmten Wertebereich. Du kannst die
Tabelle schliesslich nicht beliebig gross machen. Irgendwann wird
dadurch aber auch diese Tabelle zu klein. Bei (theoretisch) unbegrenzt
vielen Daten ist eine Hash-Tabelle einfach nicht das wahre, akzeptiere
das doch einfach ;-)Die Daten sind aber 1. nicht unbegrenzt weil wir nur ein begrenztes
Vokabular haben (Selfdeutsch und deine "??" ;),
Und was hindert mich daran, jeden Tag eine neue Wortschoepfung zu
kreieren? Sorry, aber das ist doch Quatsch. Weder weisst du, wie welcher
Mensch welche Worte schreibst, noch weisst du, welche Wortschoepfungen
eventuell kreiert werden koennen.
ausserdem gehst du glaube ich von einem geschlossenen Hash aus, ich
aber von einem offenen. Was spricht also dagegen als Hashwert wiederum
einen weiteren Hash zu haben, der alle möglichen Kollisionen beinhaltet?
Weil es dir schwerfallen duerfte, die Datei entsprechend zu organisieren.
Je genauer der Hash-Wert, desto groesser die Hash-Tabelle. In der zweiten
Stufe muesste der Hash-Wert um einiges genauer sein als in der ersten
Stufe, dadurch wuerdest du n Hash-Tabellen mit beachtlicher Groesse
aufbauen muessen. Gehen wir mal davon aus, du hast in der ersten Tabelle
Hash-Werte von 16 Bit, dann kannst du darin maximal 65536 Werte
unterbringen. Arbeitest du mit 32Bit-Datei-Pointern, hast du damit schon
256KB verbraucht. In der zweiten Stufe muesstest du dann am besten mit
einer 2er-Potenz mehr arbeiten, damit haettest du 32 Bit Hashwerte und
maximal 4294967296 Eintraege a 32 Bit. Damit kaemst du auf 131072MB
fuer die zweite Hash-Tabelle.
再见,
CK
Hi Christian,
Die Daten sind aber 1. nicht unbegrenzt weil wir nur ein begrenztes
Vokabular haben (Selfdeutsch und deine "??" ;),Und was hindert mich daran, jeden Tag eine neue Wortschoepfung zu
kreieren? Sorry, aber das ist doch Quatsch. Weder weisst du, wie welcher
Mensch welche Worte schreibst, noch weisst du, welche Wortschoepfungen
eventuell kreiert werden koennen.
Versuche mal ein Posting abzusetzen dass nur aus Neukreationen besteht.
Mein Argument ist das ein Suchalgo auf die Häufigkeitsverteilung von Wörtern/Silben im Archiv/bei der Suche orientiert. Diese wirst du mit gelegentlichen Neukreationen nicht so schnell umstoßen können, es sei denn das Forum entschließt sich spontan z.B. auf finnisch weiterzudiskutieren.
einer 2er-Potenz mehr arbeiten, damit haettest du 32 Bit Hashwerte und
maximal 4294967296 Eintraege a 32 Bit. Damit kaemst du auf 131072MB
fuer die zweite Hash-Tabelle.
Nein nein nein, es geht um verschachtelte Hashtabellen.
Das Primärhash enthält in jeder Zelle einen Verweis auf ein weiteren _neuen_ Hash mit _nur_ den Kollisionen (und zusätzlich natürlich gleich den Hauptwert für den häufigsten (oder die häufigsten) Schlüssel).
Wenns in dieser Zelle nur 256 Kollisonen gibt, ist der neue Hash entsprechend klein, dh. 8 statt 32 bit Hashwerte.
65K war jetzt nur eine Hausnummer die sich am Standardvokabular eines Menschen orientiert, (weniger wär wahrscheinlich auch effektiver), so dass
Abfragen die einen sekundären Hash brauchen möglichst selten sind.
Dein Argument das Hashes nicht dynamisch erweiterbar sind, ist aber damit widerlegt.
Tschau
rolf
你好 LanX!,
Die Daten sind aber 1. nicht unbegrenzt weil wir nur ein begrenztes
Vokabular haben (Selfdeutsch und deine "??" ;),Und was hindert mich daran, jeden Tag eine neue Wortschoepfung zu
kreieren? Sorry, aber das ist doch Quatsch. Weder weisst du, wie welcher
Mensch welche Worte schreibst, noch weisst du, welche Wortschoepfungen
eventuell kreiert werden koennen.Versuche mal ein Posting abzusetzen dass nur aus Neukreationen besteht.
Mein Argument ist das ein Suchalgo auf die Häufigkeitsverteilung von
Wörtern/Silben im Archiv/bei der Suche orientiert. Diese wirst du mit
gelegentlichen Neukreationen nicht so schnell umstoßen können, es sei
denn das Forum entschließt sich spontan z.B. auf finnisch
weiterzudiskutieren.
Darum ging es doch gar nicht. Es ging darum, dass du das Vokabular als
eine feste Zahl gesehen hast. Fakt ist, dass das Vokabular alles andere
als fest ist, wie ich dir gerade bewiesen habe.
einer 2er-Potenz mehr arbeiten, damit haettest du 32 Bit Hashwerte und
maximal 4294967296 Eintraege a 32 Bit. Damit kaemst du auf 131072MB
fuer die zweite Hash-Tabelle.Nein nein nein, es geht um verschachtelte Hashtabellen.
Ja, das habe ich schon verstanden.
Das Primärhash enthält in jeder Zelle einen Verweis auf ein weiteren
_neuen_ Hash mit _nur_ den Kollisionen
Ja. Und um diese Kollisionen aufzuloesen muss dein Hash-Wert genauer sein
als der in der ersten Tabelle, optimalerweise um eine Zweier-Potenz.
Dein Argument das Hashes nicht dynamisch erweiterbar sind, ist aber
damit widerlegt.
Das sehe ich anders.
再见,
CK
Hi CK,
Darum ging es doch gar nicht. Es ging darum, dass du das Vokabular als
eine feste Zahl gesehen hast. Fakt ist, dass das Vokabular alles andere
als fest ist, wie ich dir gerade bewiesen habe.
Das Gesamtvokabular ist absolut natürlich nicht fest, potentiel aber schon. Es macht keinen Sinnden gleichen Aufwand für Nischenwörter zu betreiben die jenseits des Standardvokabulars sind.
Check doch mal wieviele der Suchbegriffe nicht zu den 65000 häufigsten gehören.
Ja. Und um diese Kollisionen aufzuloesen muss dein Hash-Wert genauer sein
als der in der ersten Tabelle, optimalerweise um eine Zweier-Potenz.
Gehst du davon aus dass ich immer die gleiche Hashfunktion benutze? Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???
tschau
rolf
你好 LanX!,
Darum ging es doch gar nicht. Es ging darum, dass du das Vokabular als
eine feste Zahl gesehen hast. Fakt ist, dass das Vokabular alles andere
als fest ist, wie ich dir gerade bewiesen habe.Das Gesamtvokabular ist absolut natürlich nicht fest, potentiel aber
schon. Es macht keinen Sinnden gleichen Aufwand für Nischenwörter zu
betreiben die jenseits des Standardvokabulars sind.
Also soll ich demnaechst nur noch nach Standard-Vokabeln suchen koennen?
Na vielen Dank...
Ja. Und um diese Kollisionen aufzuloesen muss dein Hash-Wert genauer
sein als der in der ersten Tabelle, optimalerweise um eine
Zweier-Potenz.Gehst du davon aus dass ich immer die gleiche Hashfunktion benutze?
Selbst wenn du eine andere benutzt, bekommst du dieselben Probleme. In
dem Fall vielleicht eher spaeter als frueh, aber du bekommst sie. Mal
abgesehen davon, dass irgendwann die Hash-Tabelle einfach voll ist und
du deine Tabelle neu aufbauen musst und den Schluessel vergroessern
musst (sinvollerweise um eine Zweier-Potenz).
Du musst sehen, wie Hash-Tabellen funktionieren. Hash-Tabellen sind
_Tabellen_, wie der Name schon sagt. Eine Tabelle hat eine bestimmte
Groesse, zwangslaeufig. Deshalb muss der Schluessel auch zwangslaeufig
auf eine bestimmte Genauigkeit beschraenkt werden. Ist jetzt die Tabelle
irgendwann voll (heisst, es gibt hinreichend viele Duplikate) gibt es
zwei Moeglichkeiten: Tabelle vergroessern, was eine vollstaendige
Reorganisation nach sich zieht, oder anfangen mit indirekten Tabellen zu
arbeiten, was zumindest teilweise eine Reorganisation benoetigt. Im ersten
Fall hast du nach einer Zeit wieder die gleichen Probleme: die Tabelle
wird zu klein, es gibt hinreichend viele Duplikate, die Performance wird
also scheisse. Im zweiten Fall dauert das vermutlich zwar tendentiell
laenger, aber die Probleme sind dieselben: irgendwann hast du auch in
dieser Stufe hinreichend viele Duplikate. Du kannst jetzt natuerlich
versuchen, eine Dritte Stufe aufzumachen, aber was bringt das? Auch da
stoesst man frueher oder spaeter an die Grenzen...
Nein, Hashes sind einfach nicht gut geeignet fuer eine theoretisch
unbegrenzte Eingabemenge. Das liegt in der Natur der Sache, aber das
solltest du als Mathematiker doch auch sehen? Wenn ich eine Funktion
f : |D -> \W habe, wobei |D = |R und \W = {1,2,...,2^32}, dann ist doch
abzusehen, dass die Funktion nicht injektiv ist und es unendlich viele
Werte in |D gibt, die auf ein einzelnes Element von \W abbilden. Egal,
wie gross du \W machst, wenn du es nicht unendlich gross machst, wirst
du immer unendlich viele Werte in |D haben, die zu einem einzelnen
Element aus \W abbilden.
Aber ich mache dir einen Vorschlag. Du erstellst eine funktionierende
Loesung, die theoretisch (bei unendlich viel Speicher) mit unendlich
vielen Daten klarkommt und dann werde ich dir haltlos zustimmen. Eine
weitere Diskussion duerfte nicht viel bringen. «Du glaubst mir ja eh
nicht!»
Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???
Der hoeheren Genauigkeit wegen. Die Genauigkeit muss doch hoeher sein als
in der ersten Stufe.
再见,
CK
Hallo Christian,
Wir reden aneinander vorbei, anders gefragt:
Stell dir vor wir lassen die Hashes der nten Stufe weg (die diesbezüglichen Schlüssel bleiben z.B. in der DB), und wir bauen nur einen "perfekten" Hash der 2^16 häufigsten Suchbegriffe auf (z.B. mit dem Tool das Christoph erwähnte). Ist der Suchbegriff nicht im Hash wird er dann klassisch über binärbaum in der DB gesucht.
Wäre es dann von der Gesamtperformance nicht besser, wenn in über 95% der Fälle nur auf diesen Hash zugegriffen werden müßte?
(vorausgesetzt diese "perfekte" Hashfkt ist selbst performant, da seh ich den Haken...)
Natürlich hast du unter deinen Annahmen recht. Wenn das Vokabular ähnlich stark wachsen würde wie die Zahl der Postings würde mein Ansatz keinen Sinn machen. Dieses tut es aber IMHO nicht, weil keine Randomfunktionen posten sondern Deutschsprecher.²
Ich optimiere aber im Hinblick auf dieses Userverhalten!
weitere Diskussion duerfte nicht viel bringen. «Du glaubst mir ja eh
nicht!»
doch ich weiß zwar ad hoc nicht wieso der Exponent des Schlüssels in 2er Schritten wachsen muß, außer das Chips so organisiert sind, aber ich glaube dir unter deinen Annahmen.
Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???
Der hoeheren Genauigkeit wegen. Die Genauigkeit muss doch hoeher sein als
in der ersten Stufe.
Allerdings wieso könnte ich - theoretisch - nicht mit diesem Perfekte-Hashfkt-Bastel-Tool nicht einen neuen Hash für 256 Einträge basteln??? (ausser das der overhead für die Funktion eventuell größer ist als die Tabelle?)
Ehrlich gesagt ich hätte sowieso ein Problem damit für 256 Werte einen Hash zu nehmen, deswegen sagte ich "geeignet Datenstruktur". Diese geeignete Datenstruktur kann auch teuer sein, weil sie selten gebraucht wird.
Tschau
rolf
²Ich hätte noch erwähnen sollen das man zusammengesetzte Wörter auch in Einzelteile zerlegen sollte um ein gutes Ergebnis zu haben.
你好 LanX!,
Wir reden aneinander vorbei, anders gefragt:
Stell dir vor wir lassen die Hashes der nten Stufe weg (die
diesbezüglichen Schlüssel bleiben z.B. in der DB), und wir bauen
nur einen "perfekten" Hash der 2^16 häufigsten Suchbegriffe auf (z.B.
mit dem Tool das Christoph erwähnte). Ist der Suchbegriff nicht im
Hash wird er dann klassisch über binärbaum in der DB gesucht.Wäre es dann von der Gesamtperformance nicht besser, wenn in über 95%
der Fälle nur auf diesen Hash zugegriffen werden müßte?
Das war ja gar nicht die Frage, die sich entwickelt hat ;-) Die Frage,
die sich entwickelt hat, war, ob Hashes dazu geeignet sind, sehr grosse
Datenmengen zu speichern.
Natürlich hast du unter deinen Annahmen recht. Wenn das Vokabular
ähnlich stark wachsen würde wie die Zahl der Postings würde mein
Ansatz keinen Sinn machen. Dieses tut es aber IMHO nicht, weil
keine Randomfunktionen posten sondern Deutschsprecher.²
Du vergisst, dass hier viel Quelltext gepostet wird, dass hier jeden Tag
sich Leute verschreiben, etc, pp. -- ich halte die Wachstumsrate “neuer
Woerter” fuer groesser, ehrlich gesagt.
weitere Diskussion duerfte nicht viel bringen. «Du glaubst mir ja eh
nicht!»doch ich weiß zwar ad hoc nicht wieso der Exponent des Schlüssels in
2er Schritten wachsen muß, außer das Chips so organisiert sind, aber
ich glaube dir unter deinen Annahmen.
Er muss nicht in Zweier-Potenzen wachsen, aber es ist sinnvoll, weil dann
die Genauigkeit des Schluessels sehr einfach eingestellt werden
kann (Grosser-Key & (1<<Genauigkeit)).
Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???
Der hoeheren Genauigkeit wegen. Die Genauigkeit muss doch hoeher
sein als in der ersten Stufe.Allerdings wieso könnte ich - theoretisch - nicht mit diesem
Perfekte-Hashfkt-Bastel-Tool nicht einen neuen Hash für 256
Einträge basteln??? (ausser das der overhead für die Funktion
eventuell größer ist als die Tabelle?)
Ehrlich gesagt ich hätte sowieso ein Problem damit für 256 Werte
einen Hash zu nehmen, deswegen sagte ich "geeignet Datenstruktur".
Diese geeignete Datenstruktur kann auch teuer sein, weil sie selten
gebraucht wird.
Das sagst du ;-) Ich denke etwas anderes. Wie gesagt, ich wette, ich habe allein in diesem Posting schon midnestens einen Recktschriebfaehlah.
再见,
CK
Hi Christian
Das war ja gar nicht die Frage, die sich entwickelt hat ;-)
wir haben aneinander vorbeigefragt.
Die Frage,
die sich entwickelt hat, war, ob Hashes dazu geeignet sind, sehr grosse
Datenmengen zu speichern.
das war aber deine Frage. Beantworte zur Abwechlung mal meine letzte! :) Wäre es schneller?
Du vergisst, dass hier viel Quelltext gepostet wird, dass hier jeden Tag
sich Leute verschreiben, etc, pp. -- ich halte die Wachstumsrate “neuer
Woerter” fuer groesser, ehrlich gesagt.
Quelltext wäre auch perfekt weil das Vokabular ja standardisiert ist.
Rechtschreibfehler habe ich ja auch angesprochen in dem die gängigen Fehler eines Wortes idealerweise auf den gleichen Hashwert mappen sollten. (fehlender Buchstabe, geswapte Buchstaben,...), außerdem sollten die Wörter gestämmt werden.
Diese geeignete Datenstruktur kann auch teuer sein, weil sie selten
gebraucht wird.Das sagst du ;-) Ich denke etwas anderes. Wie gesagt, ich wette, ich habe allein in diesem Posting schon midnestens einen Recktschriebfaehlah.
Und lange wörter sollten zerlegt werden.
Tschau
rolf
PS: ist eigentlich bekannt wie die googlesuche arbeitet?
你好 LanX!,
Die Frage,
die sich entwickelt hat, war, ob Hashes dazu geeignet sind, sehr grosse
Datenmengen zu speichern.das war aber deine Frage.
Ja, klar war das meine Frage. Das war es doch, worauf ich dich aufmerksam
machen wollte.
Beantworte zur Abwechlung mal meine letzte! :) Wäre es schneller?
So ohne weiteres nicht beantwortbar. Haengt von vielen Faktoren ab, u.a.
davon, wie gross die Ergebnismengen der einzelnen Suchbegriffe sind.
Du vergisst, dass hier viel Quelltext gepostet wird, dass hier jeden Tag
sich Leute verschreiben, etc, pp. -- ich halte die Wachstumsrate “neuer
Woerter” fuer groesser, ehrlich gesagt.Quelltext wäre auch perfekt weil das Vokabular ja standardisiert ist.
Falsch! Das Vokabular bei Quelltexten ist genau eben _nicht_
standardisiert. Ich kann meine Funktion benennen, wie ich lustig bin...
Rechtschreibfehler habe ich ja auch angesprochen in dem die gängigen
Fehler eines Wortes idealerweise auf den gleichen Hashwert mappen
sollten. (fehlender Buchstabe, geswapte Buchstaben,...), [...]
Du hast Vorstellungen... eine wichtige Eigenschaft einer Hash-Funktion
ist es, dass kleine Aenderungen im Eingangswert grosse Aenderungen im
Ausgangswert verursachen. Sonst wird die Wahrscheinlichkeit fuer
Kollisionen zu gross (z. B. Maße und Masse muesste deiner Definition nach
die gleiche Hash-Summe ergeben, ist aber etwas anderes -- das Beispiel
ist jetzt konstruiert, ich bin mir aber sicher, im normalen Fach-Vokabular
treten bessere Beispiele auf).
[...] außerdem sollten die Wörter gestämmt werden.
*g* also, jetzt faengst du an zu fantasieren. Wie willst du maschinell
das Wort auf seinen Stamm zurueckfuehren?
Diese geeignete Datenstruktur kann auch teuer sein, weil sie selten
gebraucht wird.Das sagst du ;-) Ich denke etwas anderes. Wie gesagt, ich wette, ich
habe allein in diesem Posting schon midnestens einen
Recktschriebfaehlah.Und lange wörter sollten zerlegt werden.
Damit machst du die Eingangsmenge aber noch groesser.
再见,
CK
Hi
Du vergisst, dass hier viel Quelltext gepostet wird, dass hier jeden Tag
sich Leute verschreiben, etc, pp. -- ich halte die Wachstumsrate “neuer
Woerter” fuer groesser, ehrlich gesagt.Quelltext wäre auch perfekt weil das Vokabular ja standardisiert ist.
Falsch! Das Vokabular bei Quelltexten ist genau eben _nicht_
standardisiert. Ich kann meine Funktion benennen, wie ich lustig bin...
ja aber bitte ...
1. wieviele Leute benennen ihre Fkten iopiwejdiendkn(), statt getUpper().
2. wieviele Leute suchen dann auch iopiwejdiendkn()
3. im Falle 2., wie schnell soll die suche in diesem Sonderfall erfolgen?
4. Wieviel Prozent des Quellcodes machen selbstdefinierte Funktionennamen aus?
Wird ein Funktionenname hingegen oft gesucht, dann bildet er einen stehenden Begriff der günstig indiziert sein sollte, z.B. instr() findest du nicht im Duden gehört aber zu "Selfdeutsch" (~140 Archivtreffer)
Rechtschreibfehler habe ich ja auch angesprochen in dem die gängigen
Fehler eines Wortes idealerweise auf den gleichen Hashwert mappen
sollten. (fehlender Buchstabe, geswapte Buchstaben,...), [...]
Du hast Vorstellungen... eine wichtige Eigenschaft einer Hash-Funktion
ist es, dass kleine Aenderungen im Eingangswert grosse Aenderungen im
Ausgangswert verursachen. Sonst wird die Wahrscheinlichkeit fuer
Kollisionen zu gross (z. B. Maße und Masse muesste deiner Definition nach
die gleiche Hash-Summe ergeben, ist aber etwas anderes -- das Beispiel
ist jetzt konstruiert, ich bin mir aber sicher, im normalen Fach-Vokabular
treten bessere Beispiele auf).
Ja, hast recht, dass sollte eine Vorfunktion leisten, d.h. es wird H(k('Maße'))=H('Masse') gesucht, mit k der Korrekturfunktion.
Die "Korrekturkollisionen" werden dann auch nachträglich aufgelöst, d.h. sofern gewollt (das erlaubt ansonsten eine Ähnlichkeitssuche)
Beispiel:
|goggle(Rechtschreibfelher)| = 96
|goggle(Rechtschreibfehler)| = 403.000
Nochmal, mir gehts darum Eigenschaften der Sprache zur Optimierung zu nutzen, für seltene Rechtschreibfelher eigene Zellen im Index (unabhängig ob Hash oder DB) zu belegen rechnet sich IMHO nicht.
[...] außerdem sollten die Wörter gestämmt werden.
*g* also, jetzt faengst du an zu fantasieren. Wie willst du maschinell
das Wort auf seinen Stamm zurueckfuehren?
Algorithmisch natürlich nicht in 100% aller Fälle, aber bei den regelmäßigen Beugungen reicht es einfach bestimmte Endungen zu streichen. (e, en ,er,...)
Ansonsten mit Wörterbuch, falls es sich's von der Performance her rechnet. (???)
Und lange wörter sollten zerlegt werden.
Damit machst du die Eingangsmenge aber noch groesser.
Hä? Die Menge der Wörter im Index werden kleiner wenn die Zusammengesetzten wegfallen!
also |k(Selfdeutsch)| << |Selfdeutsch|
Um Akkurat zu arbeiten bräuchte man tatsächlich ein Wörterbuch, nicht bei jedem Wort lohnt die Trennung.
Bye
rolf
你好 LanX²,
Du vergisst, dass hier viel Quelltext gepostet wird, dass hier
jeden Tag sich Leute verschreiben, etc, pp. -- ich halte die
Wachstumsrate “neuer Woerter” fuer groesser, ehrlich gesagt.Quelltext wäre auch perfekt weil das Vokabular ja standardisiert ist.
Falsch! Das Vokabular bei Quelltexten ist genau eben _nicht_
standardisiert. Ich kann meine Funktion benennen, wie ich lustig bin...ja aber bitte ...
- wieviele Leute benennen ihre Fkten iopiwejdiendkn(), statt getUpper().
Nur weil du es ueberziehst, heisst das ja nicht, dass Funktionsnamen sehr
voneinander differieren.
- wieviele Leute suchen dann auch iopiwejdiendkn()
- im Falle 2., wie schnell soll die suche in diesem Sonderfall erfolgen?
Das ist doch hier nebensaechlich, das hatten wir doch schon
festgestellt :) Aktuell geht es doch nur darum, ob die Eingabemenge im Fall
des Forums unendlich ist oder nicht.
- Wieviel Prozent des Quellcodes machen selbstdefinierte
Funktionennamen aus?
Zusammen mit Variablennamen etwa 50%, wuerde ich vermuten, wenn nicht mehr.
Rechtschreibfehler habe ich ja auch angesprochen in dem die gängigen
Fehler eines Wortes idealerweise auf den gleichen Hashwert mappen
sollten. (fehlender Buchstabe, geswapte Buchstaben,...), [...]Du hast Vorstellungen... eine wichtige Eigenschaft einer Hash-Funktion
ist es, dass kleine Aenderungen im Eingangswert grosse Aenderungen im
Ausgangswert verursachen. Sonst wird die Wahrscheinlichkeit fuer
Kollisionen zu gross (z. B. Maße und Masse muesste deiner Definition
nach die gleiche Hash-Summe ergeben, ist aber etwas anderes -- das
Beispiel ist jetzt konstruiert, ich bin mir aber sicher, im normalen
Fach-Vokabular treten bessere Beispiele auf).Ja, hast recht, dass sollte eine Vorfunktion leisten, d.h. es wird
H(k('Maße'))=H('Masse') gesucht, mit k der Korrekturfunktion.Die "Korrekturkollisionen" werden dann auch nachträglich aufgelöst, d.h.
sofern gewollt (das erlaubt ansonsten eine Ähnlichkeitssuche)Beispiel:
|goggle(Rechtschreibfelher)| = 96
|goggle(Rechtschreibfehler)| = 403.000
Das wuerde aber bedeuten, dass man wieder eine nachgeschaltete
Volltext-Suche machen muss. Doof, damit wuerde man alles wieder
verschenken.
[...] außerdem sollten die Wörter gestämmt werden.
*g* also, jetzt faengst du an zu fantasieren. Wie willst du maschinell
das Wort auf seinen Stamm zurueckfuehren?Algorithmisch natürlich nicht in 100% aller Fälle, aber bei den
regelmäßigen Beugungen reicht es einfach bestimmte Endungen zu
streichen. (e, en ,er,...)
Das zeig mir doch bitte mal, wie du das machen willst ;-)
Und lange wörter sollten zerlegt werden.
Damit machst du die Eingangsmenge aber noch groesser.
Hä? Die Menge der Wörter im Index werden kleiner wenn die
Zusammengesetzten wegfallen!
Du hast von langen Woertern, nicht von zusammengesetzten Woertern geredet.
再见,
CK
Hi Christian,
Vorweg, die Diskussion über Stämmer und Fehlerkorrektur
ist unabhängig von der Suchtechnologie zu sehen, also Binärer Baum als auch Hash sollen davon profitieren dass
weniger Wörter indiziert werden müssen.
Zusammen mit Variablennamen etwa 50%, wuerde ich vermuten, wenn nicht mehr.
hmm ... ich denke auch bei Variablennamen kommt nicht jede Permutation gleich häufig vor, weil man sie schließlich ja auch aussprechen möchte.
Die "Korrekturkollisionen" werden dann auch nachträglich aufgelöst, d.h.
sofern gewollt (das erlaubt ansonsten eine Ähnlichkeitssuche)Beispiel:
|goggle(Rechtschreibfelher)| = 96
|goggle(Rechtschreibfehler)| = 403.000Das wuerde aber bedeuten, dass man wieder eine nachgeschaltete
Volltext-Suche machen muss. Doof, damit wuerde man alles wieder
verschenken.
naja, wie bei Danielas Phrasensuche auch hängts davon ab wie teuer der Zugriff auf Michaels Vollindex ist, dort wo sie auch ihre "Kollisionen" auflöst.
Man könnte sich auch entscheiden die Überprüfung nur bei
eingetipptem 'Rechtschreibfelher' zu machen, schließlich ist ja in der Zelle hinterlegt das diese für "Rechtschreibfehler" gedacht ist. Eine teure Überprüfung käme also nur bei unkorrekten Suchbegriffen zustande.
Man könnte die Überprüfung am effizientesten mit einer nachträglich gesuchten Zelle für 'Rechtschreibfelher' machen, die nicht im RAM liegt, weil offensichtlich ist, dass falsche Schreibweisen zu selten gesucht werden. (wieder das Argument mit den häufigsten Suchbegriffen)
regelmäßigen Beugungen reicht es einfach bestimmte Endungen zu
streichen. (e, en ,er,...)Das zeig mir doch bitte mal, wie du das machen willst ;-)
wie gesagt, übliche Endungen streichen.
suchen, suchte, Suche, Sucher, suchten ->such
Es gibt Wörter bei denen so eine Kürzung aber natürlich fatal wäre die müßten beim Archivieren also ungekürzt in den Index abgelegt werden (z.B. 'Heer' nicht zu 'He' verkürzen).
Die Suche müßte dann oft mehrfach laufen, erst wird 'Heer' oder 'Sucher' gesucht, nur Heer gefunden, dann 'Suche' vergeblich und schließlich 'such' gefunden.
Die Frage ob sich das rechnet hängt vom Geschwindigkeitsgewinn durch kleineren Index gegenüber
worstcase 3-facher Suche ab...
... ich bin verunsichert ...
... also ich hab für eine JS-Volltextsuche schon mal so einen Stämmer gewinnbringend realisiert, da war mir aber ein kleiner Suchindex im Download auch wichtiger ...
Ich denke bei der Selfsuche gilt: Könnte ein signifikanter Großteil der Suchanfragen dank Stämmen und Fehlerkorrektur komplett im RAM stattfinden, würde es sich auch lohnen.
Alternativ könnte man sich auch überlegen, in einer Zelle die Info über erlaubte Nebenversionen mit abzulegen, ähnlich wie in Wörterbüchern. Soll heißen die Zelle von 'such' beinhaltet auch eine Liste erlaubter Endungen (e|en|te|...)
Und lange wörter sollten zerlegt werden.
Damit machst du die Eingangsmenge aber noch groesser.
Hä? Die Menge der Wörter im Index werden kleiner wenn die
Zusammengesetzten wegfallen!Du hast von langen Woertern, nicht von zusammengesetzten Woertern geredet.
Stimmt, aber wieso wird die Eingangsmenge größer wenn die "längeren" wegfallen? >:)
Bye
Rolf
你好 LanX!,
Zusammen mit Variablennamen etwa 50%, wuerde ich vermuten, wenn nicht
mehr.hmm ... ich denke auch bei Variablennamen kommt nicht jede Permutation
gleich häufig vor, weil man sie schließlich ja auch aussprechen möchte.
Ich habe noch nie meine Variablen-Namen auf aussprechbarkeit hin
gewaehlt, krkr. Du kannst nicht automatisch von dir auf andere schliessen.
Die "Korrekturkollisionen" werden dann auch nachträglich aufgelöst,
d.h. sofern gewollt (das erlaubt ansonsten eine Ähnlichkeitssuche)Beispiel:
|goggle(Rechtschreibfelher)| = 96
|goggle(Rechtschreibfehler)| = 403.000Das wuerde aber bedeuten, dass man wieder eine nachgeschaltete
Volltext-Suche machen muss. Doof, damit wuerde man alles wieder
verschenken.naja, wie bei Danielas Phrasensuche auch hängts davon ab wie teuer
der Zugriff auf Michaels Vollindex ist, dort wo sie auch ihre
"Kollisionen" auflöst.
Daniela muss doch gar keine Kollisionen aufloesen, Mooeensch ;-) Da wird
exakt gematcht. Bei Daniela geht es um eine eventuelle anschliessende
Phrasensuche.
regelmäßigen Beugungen reicht es einfach bestimmte Endungen zu
streichen. (e, en ,er,...)Das zeig mir doch bitte mal, wie du das machen willst ;-)
wie gesagt, übliche Endungen streichen.
Sorry, aber das halte ich fuer mehr als unrealistisch. Das zu
automatisieren birgt ziemliche Risiken, da muesste man wenn dann schon
von Hand ran.
Und lange wörter sollten zerlegt werden.
Damit machst du die Eingangsmenge aber noch groesser.
Hä? Die Menge der Wörter im Index werden kleiner wenn die
Zusammengesetzten wegfallen!Du hast von langen Woertern, nicht von zusammengesetzten Woertern
geredet.Stimmt, aber wieso wird die Eingangsmenge größer wenn die "längeren"
wegfallen? >:)
Weil du aus einem Wort n Worte machst. Also z. B. Kunstwort
Ichbineingrossermensch, ein einziges Wort. Daraus machst du (willkuerlich)
3 Worte. Und schon hast du die 3-fache Menge in der Eingabemenge.
再见,
CK
Hi,
regelmäßigen Beugungen reicht es einfach bestimmte Endungen zu
streichen. (e, en ,er,...)Das zeig mir doch bitte mal, wie du das machen willst ;-)
wie gesagt, übliche Endungen streichen.
Sorry, aber das halte ich fuer mehr als unrealistisch. Das zu
automatisieren birgt ziemliche Risiken, da muesste man wenn dann schon
von Hand ran.
Kleine Argumentationshilfe:
Es gibt tatsächlich Regeln, die es ermöglichen den Wortstamm herauszufinden. Das geht sogar automatisch, wenn auch nicht vollständig, da es ja immer einige Ausnahmen gibt, aber das spielt hier keine Rolle. Nun hast Du aber ein kleines Problem in allen natürlich gewachsenen Sprachen mit Affix-Grammatik: je nach Wortbedeutung gilt eine unterschiedliche Regel. Je nachdem, ob es ein Substantiv ist, ein Verb oder ein Adjektiv; männlich, sächlich oder weiblich ist; viele oder nur einer betroffen sind (Regeländerung aus dem Kontext heraus!) usw usf. Diese Wortbedeutungen hast Du bei der Spracherlernung _auswendig_ gelernt, dafür gibt es keine Regel. Deshalb ist vollständig automatisiertes Stemming ohne Lexikon nicht möglich.
BTW: so ein Lexikon ist bei Ispell übrigens mit dabei ...
Nein, setz Dich wieder hin, ich weiß, was das für ein Aufwand wäre und hat auch sowieso nix mit dem Backend zu tun, wäre ein Plugin für's Formular, für's Frontend also.
so short
Christoph Zurnieden
你好 Christoph,
regelmäßigen Beugungen reicht es einfach bestimmte Endungen zu
streichen. (e, en ,er,...)Das zeig mir doch bitte mal, wie du das machen willst ;-)
wie gesagt, übliche Endungen streichen.
Sorry, aber das halte ich fuer mehr als unrealistisch. Das zu
automatisieren birgt ziemliche Risiken, da muesste man wenn dann schon
von Hand ran.Kleine Argumentationshilfe:
Es gibt tatsächlich Regeln, die es ermöglichen den Wortstamm
herauszufinden.
Das mag vielleicht bei Webseiten gehen, die lediglich natuerliche Sprache
enthalten. Ich bezweifle aber ernsthaft, dass es hier moeglich waere: die
Sprache besteht aus vielen Fachbegriffen und viel Quellcode, den man
tendentiell nicht unterscheiden kann von dem Rest.
[...] Deshalb ist vollständig automatisiertes Stemming ohne Lexikon
nicht möglich.
Sagichdoch! ;-)
再见,
CK
Hi
[...] Deshalb ist vollständig automatisiertes Stemming ohne Lexikon
nicht möglich.Sagichdoch! ;-)
Soweitwarenwir schon! ;-)
Das teure Lexikon käme aber nur beim archivieren zum zuge. Allerdings müßte man durchrechnen ob der ganze Aufwand überhaupt Performancegewinn bei der Suche brächte ...
Am Rande: Diese ganzen Techniken (stämmen, zusammengesetzte wörter zerlegen, buchstabendreher rausfiltern) werden bei Textanalysen eingesetzt, um den Verwandschaftsgrad zweier Texte anhand gemeinsamer Wörter zu ermitteln.
In der Art: "Suche mir andere Postings zum gleichen Thema"
Tschau
rolf
PS: Ich merke gerade dass ich in Bezug auf Rechtschreibung zu den Topverschmutzern des Forums gehöre...
Hi Christian,
Hi
Sorry, aber das halte ich fuer mehr als unrealistisch. Das zu
automatisieren birgt ziemliche Risiken, da muesste man wenn dann schon
von Hand ran.
da ...
Weil du aus einem Wort n Worte machst. Also z. B. Kunstwort
Ichbineingrossermensch, ein einziges Wort. Daraus machst du (willkuerlich)
3 Worte. Und schon hast du die 3-fache Menge in der Eingabemenge.
... gebe ich dir recht! :)
Tschau
rolf
Hi,
Check doch mal wieviele der Suchbegriffe nicht zu den 65000 häufigsten gehören.
Wahrscheinlich die meisten. Merkwürdig? nein, eigentlich gar nicht, denn die ist ein Fachforum, deshalb wird nach Fachbegriffen gesucht, die selten im allgemeinem Wortschatz stecken. Das sind aber nur sehr wenige. Was viel interessanter wäre, aber leider sehr viel Handarbeit erfordert (wer macht das? Genau, keiner) wäre ein Thesaurus. Ich hatte das am Anfang schon mal kurz andiskutiert (ich glaube mit Daniela selber), mußte mich aber recht schnell davon überzeugen lassen, das das einfach zuviel Arbeit ist.
Was geht an Optimierung ist ein Cache. Der ist aber natürlich erst dann einzubauen, wenn die Suche selber gut und stabil funktioniert. Wenn es dann überhaupt noch nötig sein sollte. (Der wäre dann aber getrennt von DB und Frontend, könnte also ein Drittanbieter einbauen. Du vielleicht?)
Ja. Und um diese Kollisionen aufzuloesen muss dein Hash-Wert genauer sein
als der in der ersten Tabelle, optimalerweise um eine Zweier-Potenz.Gehst du davon aus dass ich immer die gleiche Hashfunktion benutze? Wieso brauche ich für 256 Einträge 32-Bit Schlüssel???
Ich glaube Christian hat Dich einfach mißverstanden. Du meintest die normale Kollisionsbehandlung durch Mehrfachhashing, oder? Das ist aber zu aufwendig. Die normalen Methoden sind da einfacher und meist sogar schneller. Der einzige Vorteil der Mehrfachhash-Methode ist es, das die Hashtabellen kleiner gehalten werden können. Idealerweise sollte die Hastabelle etwa 25% größer sein als nötig, beim Mehrfachhashing kann sie jedoch rein theoretisch genau passend sein. Man spart also ein rundes Fünftel Platz, muß aber dafür viele Hashfunktionen vorhalten (bzw dynamisch erzeugen können) und die auch ausführen (wenn man es genau besieht könnte das sogar O(n^2) als Worst Case haben anstatt der üblichen O(n), aber da möchte ich mich nicht ohne genaue Untersuchung festlegen). Es ist also das alte Geschäft: Zeit gegen Raum, Raum gegen Zeit.
so short
Christoph Zurnieden
Hi,
Check doch mal wieviele der Suchbegriffe nicht zu den 65000 häufigsten gehören.
Wahrscheinlich die meisten. Merkwürdig? nein, eigentlich gar nicht, denn die ist ein Fachforum, deshalb wird nach Fachbegriffen gesucht, die selten im allgemeinem Wortschatz stecken.
Ich meinte die häufigsten 65000 Suchbegriffe, das sind ja die Fachbegriffe.
Was geht an Optimierung ist ein Cache. Der ist aber natürlich erst dann einzubauen, wenn die Suche selber gut und stabil funktioniert. Wenn es dann überhaupt noch nötig sein sollte.
eher nicht, ich finde die alte Suche aktuell schon performant genug. Für mich ist es eine theoretische Diskussion.
(Der wäre dann aber getrennt von DB und Frontend, könnte also ein Drittanbieter einbauen. Du vielleicht?)
Ähm könnte ich, aber ich bin sicher die DB hat selbst konfigurierbare cachingfeatures die aus Projektsicht favorisiert würden.
Ich glaube Christian hat Dich einfach mißverstanden. Du meintest die normale Kollisionsbehandlung durch Mehrfachhashing, oder?
wenn Mehrfachhashing genestete Hashes sind, ja!
Das ist aber zu aufwendig. Die normalen Methoden sind da einfacher und meist sogar schneller. Der einzige Vorteil der Mehrfachhash-Methode ist es, das die Hashtabellen kleiner gehalten werden können. Idealerweise sollte die Hastabelle etwa 25% größer sein als nötig, beim Mehrfachhashing kann sie jedoch rein theoretisch genau passend sein. Man spart also ein rundes Fünftel Platz, muß aber dafür viele Hashfunktionen vorhalten (bzw dynamisch erzeugen können) und die auch ausführen (wenn man es genau besieht könnte das sogar O(n^2) als Worst Case haben anstatt der üblichen O(n), aber da möchte ich mich nicht ohne genaue Untersuchung festlegen). Es ist also das alte Geschäft: Zeit gegen Raum, Raum gegen Zeit.
Die unmengen an Hashfkt habe ich schon als Bottleneck erkannt, bin davon ausgegangen dass sie einfach nur selten gebraucht werden.
OK, angenommen ich nehme eine für die deutsche Sprache gute Hashfkt die 32 Bit zB \xABCD liefert.
Wenn ich die oberen 16 bits \xAB nehme könnte ich locker eine Tabelle im RAM adressieren. Von dort könnte ich nun eine weitere Tabelle die auf der Platte liegt referenzieren die ich mit den unteren 16 bit \xCD ansprechen ohne eine neue Hashfkt zu nehmen.
In der RAM-Tabelle könnte dann auch in jeder Zelle, - quasi als Caching - die wichtigsten/häufigsten Schlüssel
aus der Platten-Tabelle liegen, um einen teuren Zugriff zu vermeiden.
Nun sagt ihr nun "um Gottes Willen", das ist nicht speichereffizient, man bräuchte Plattenplatz für 2^16*2^16=4294967296 Zellen, obwohl dort nur viel weniger Schlüsselwörter enthalten sind!!!
Gut jetzt sage ich, was hindert mich daran die untere Tabelle zu verkleinern um Speichereffizient zu sein.
Angenommen es sind nur y Einträge enthalten, mit 2^(x-1)< y <2^x", dann kann ich auch eine Tabelle mit
2^x Einträgen nehmen wobei die oberen x Bits von \xCD
der Schlüssel wären, und die Werte der "unteren" Bits auf die oberen Zellen projeziert werden. Ohne zu viele uneffektive Kollisionen da die ursprüngliche Hashfkt ja bereits gut war.
Mit anderen Worten, wenn die ursprüngliche Hashfkt mit 32 Bit eine gute Verteilung hat, dann eigentlich auch eine abgeleitete Hashfkt mit weggestrichenen Bits. Wie groß x ist merke ich mir in der Mastertabelle im RAM.
Das wäre dann auch speichereffizient, weil ich im Schnitt nur 25% mehr Zellen als Werte bräuchte.
Knackpunkt wäre es also eine gute Hashfkt mit 32 Bit für die Selfsprache zu finden.
Oder irre ich mich?
Tschau
rolf
Hi,
Ich meinte die häufigsten 65000 Suchbegriffe, das sind ja die Fachbegriffe.
Soviele werden das insgesamt kaum sein, vemutlich nur ein paar Tausend, wenn überhaupt, die signifikant oft nachgefragt wurden. Aber das ist ja auch nicht das Problem, das Ärgernis liegt darin, das da täglich verschieden drauf geantwortet werden muß, denn täglich wird das Archiv geupdated. Wenn die Postingfrequenz weiter in die Höhe schnellt vielleicht sogar noch öfter am Tag. Auf die gleiche Frage bekommst Du also am Montag eine andere Antwort als am Dienstag; oder am Mittwoch oder am Donnerstag oder ...
eher nicht, ich finde die alte Suche aktuell schon performant genug.
Wenn wirklich jeder vorher erstmal suchen würde, der hier eine Frage stellt, wäre sie schon jetzt am Ende. Sie war überhaupt nicht für solch einen Andrang vorgesehen. Das sie überhaupt so lange durchgehalten hat, läßt einen den Hut vor dem Programmierer ziehen!
(Der wäre dann aber getrennt von DB und Frontend, könnte also ein Drittanbieter einbauen. Du vielleicht?)
Ähm könnte ich, aber ich bin sicher die DB hat selbst konfigurierbare cachingfeatures die aus Projektsicht favorisiert würden.
Nicht rausreden, machen. Wenn's dann nach sorgfältiger Prüfung für zu leicht befunden wurde - tja, dann hast Du eben im schlimmstem Fall eine schöne Fingerübung hinter Dir. Und das ist schließlich nichts Schlechtes!
Ich glaube Christian hat Dich einfach mißverstanden. Du meintest die normale Kollisionsbehandlung durch Mehrfachhashing, oder?
wenn Mehrfachhashing genestete Hashes sind, ja!
Als "genestet" kann man die eigentlich nicht unbedingt beschreiben? Aber gut, ich erklär's einfach mal in groben Zügen und Du sagst dann, ob Du genau das gemeint hast oder nicht:
Wenn beim Hashing eine Kollision stattfindet kann man da grundsätzlich auf zwei verschiedene Arten drangehen:
Um ein anderes unbelegtes Loch zu finden kann ich verschiedene Algorithmen anwenden: mehr oder weniger willkürlich nach links und rechts schauen, ob es da 'was Leeres gibt, oder völlig zufällig ein Loch auswählen. Mehrfachhashing nutzt die letztgenannte Methode, in dem sie einfach einen zweiten Hash ansetzt. Wird von der ersten Hashfunktion für die Eingabe "foo" das Loch 22 ausgewählt, wird von der zweiten Hashfunktion vielleicht das Loch 44 ausgegeben.
Die unmengen an Hashfkt habe ich schon als Bottleneck erkannt, bin davon ausgegangen dass sie einfach nur selten gebraucht werden.
Warum gehst Du davon aus?
OK, angenommen ich nehme eine für die deutsche Sprache gute Hashfkt die 32 Bit zB \xABCD liefert.
Das sind nur 16 Bit. Aber egal, ich weiß, was Du meinst.
Wenn ich die oberen 16 bits \xAB nehme könnte ich locker eine Tabelle im RAM adressieren.
Kommt auf die Architektur und das OS an. Normalerweise sind aber 32 bzw 64 Bit dazu nötig. Aber auch hier: egal, ich weiß, was Du meinst.
Von dort könnte ich nun eine weitere Tabelle die auf der Platte liegt referenzieren die ich mit den unteren 16 bit \xCD ansprechen ohne eine neue Hashfkt zu nehmen.
Damit hättest Du dann rein theoretisch 2^16*2^16 = 2^(16+16) = 2^32 Eintragsmöglichkeiten. Nix gewonnen. Eher etwas verloren, denn die Tabelle im Ram ist doppelt so groß, wie Du vermutest, also bleiben am Ende nur noch 2^31 Eintragsmöglichkeiten mit nutzbaren Daten über. Noch ein Problem: die Hashfunktion müßte bijektiv sein bzw Du müßtest den Suchbegriff mitgeben.
In der RAM-Tabelle könnte dann auch in jeder Zelle, - quasi als Caching - die wichtigsten/häufigsten Schlüssel aus der Platten-Tabelle liegen, um einen teuren Zugriff zu vermeiden.
Nein, das bringt nur 0,0000irgendwas% plus oder minus Gewinn. Ein Caching müßte schon vollständig sein.
Gut jetzt sage ich, was hindert mich daran die untere Tabelle zu verkleinern um Speichereffizient zu sein. Angenommen es sind nur y Einträge enthalten, mit 2^(x-1)< y <2^x", dann kann ich auch eine Tabelle mit 2^x Einträgen nehmen wobei die oberen x Bits von \xCD der Schlüssel wären, und die Werte der "unteren" Bits auf die oberen Zellen projeziert werden. Ohne zu viele uneffektive Kollisionen da die ursprüngliche Hashfkt ja bereits gut war.
"Obere" und "untere" Bits heißen auch "most signifcant bit(s)" respektive "least significant bit(s)" und das nicht ohne Grund. Du kannst so einen Hash nicht einfach in der Mitte teilen, das haut einfach nicht hin. Die Entropie des Hashwertes steckt im gesammtem Hashwert, Teile davon sind höchst unterschiedlich "zufällig". Sieht man am besten mit einem LKG-Zufallsgenerator.
---snip--- #ifndef _ISOC99_SOURCE #define _ISOC99_SOURCE #endif
#include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <string.h> #include <limits.h> #include <time.h>
static uint32_t seed;
/* linearer Kongruenzgenerator. Marke: Standard */ static uint32_t lkg( uint32_t a, uint32_t b, uint32_t N){ uint32_t result=0; result = (seed * a + b) % N; seed = result; return result; }
static uint32_t zufall(){
uint32_t ret1 = 0UL; uint32_t ret2 = 0UL;
uint32_t ret = 0UL;
uint8_t *p = NULL;
/* Da wir in eineme Durchlauf nur 16 Bit erhalten, lassen wir das 2x laufen. 32 Bit pro Anfrage sollte eine Zufallsfunktion schon mindestens liefern./ for(int i = 0; i < 2;i++){ / Zwei aufeinanderfolgende Zahlen der Folge erzeugen. / ret1 = lkg((uint32_t)397204094UL,(uint32_t)0UL,(uint32_t)2147483647UL); ret2 = lkg((uint32_t)397204094UL,(uint32_t)0UL,(uint32_t)2147483647UL); / Alle umdrehen nützt nicht viel, da die beiden mittleren Oktets auch nicht sonderlich "gut" sind. p = (uint8_t*)&ret1; for(int i = 0;i < (int)sizeof(uint32_t);i++){ tmp <<= 8; tmp |= p; p++; } ret1 = tmp;/ /* Also nur die äußeren Oktets bei der ersten Zahl austauschen. / p = (uint8_t)&ret1; *p ^= *(p+3); *(p+3) ^= *p; *p ^= (p+3); / Beide Zahlen exklusiv verodern. Durch das Umdrehen oben ist das Resultat Endianess unabhängig falls wir nicht gerade auf einer PDP-11 sitzen.
Zahl = 0x11223344 Little Endian = 0x11223344 Big Endian = 0x44332211 PDP-11 = 0x22114433
Das Problem ist bei LKGs, das die erzeugten Zahlen in Richtung LSB immer schlechter werden. Durch das XOR und das Umdrehen sind aber zumindest die beiden äußeren Oktets gleich "gut".*/ ret1 ^= ret2;
/* Füllen des Returnwertes von rechts nach links */ p = (uint8_t *)&ret1;
ret <<= i*8; ret |= *p; ret <<= 8; ret |= (p+3); } return ret; } static void seed_lkg( uint32_t i){ / normalerweise kommen hier ein paar Tests die sind aber schon in main() */ seed = i; }
int main(int argc, char **argv){
uint32_t tmp = 0UL; unsigned long count = 0, i = 0;
unsigned char *p = NULL;
seed_lkg((uint32_t)time(NULL)); if(argc > 1){ if((count = strtol(argv[1], (char **)NULL, 10)) >= ULONG_MAX/2){ fprintf(stderr,"Bitte nicht mehr als %lu, danke.\n",ULONG_MAX/2-1); exit(EXIT_FAILURE); } } else count = 1024;
for(;i<count;i++){ tmp = zufall(); p = (unsigned char )&tmp; printf("%c%c%c%c",(p+3),(p+2),(p+1),*p ); } exit(EXIT_SUCCESS); } ---snap--- (Bin jetzt zu faul, auch noch Optionsparsing einzubauen. Einfach oben einmal mit und einmal ohne Bitjuggling arbeiten (einfach auskomentieren)) Tests der Ausgabe (mit Ent bzw DIEHARD und eine LCG-crack, aber sowas gibt's tatsächlich online?) mit Bitjuggling ergaben gute Werte. Unerwarteterweise keine Wiederholung nach 2^32 Zyklen! (Ich hatte aber auch nicht mehr Platz auf der Platte als für 2^32+3 Zyklen, kann durchaus sein, das sich das einen später wiederholt hat) Wenn man nicht bloß die Bytes austauscht sondern die Bits selber gut durchschüttelt, sollte das Ergebniss noch etwas besser aussehen. Mit dem Standard-LKG entsprachen die Tests dann aber wieder voll und ganz den Erwartungen. Bevor irgendjemand Unsinn damit anstellt: das ist kein kryptographisch sicherer Pseudo-Zufallsgenerator! Auch wenn er äußerlich so aussieht.
Mit anderen Worten, wenn die ursprüngliche Hashfkt mit 32 Bit eine gute Verteilung hat, dann eigentlich auch eine abgeleitete Hashfkt mit weggestrichenen Bits.
Nein, eben nicht, siehe oben.
Knackpunkt wäre es also eine gute Hashfkt mit 32 Bit für die Selfsprache zu finden. Oder irre ich mich?
Du suchst also die perfekte Welle^WHashfunktion? Glaube nicht, das Dir das viel nützt. Das meine ich wörtlich: ich glaube nicht, das es viel nützt. Der Aufwand steht in rein gar keinem Verhältnis zum Nutzen. Selbst so "Kleinigkeiten" wie eine Rechtschreibprfüng ("Meinten sie 'Rechtschreibprüfung'"?) ist schwierig zu implementieren, sehr schwierig. Hier haut dann wieder der extrem große Umfang der Eingabemenge in's Kontor. Du könntest natürlich auch mit n-grammen arbeiten. Dann arbeitest Du aber nicht nur mit riesigen Mengen, die Du erstmal mit ein paar Regeln (welchen Regeln?) kleiner bekommen mußt, dazu kommt noch, das die Worte jedesmal gesplittet werden müssen. Ein Cache, der die Ergebnisse der häufigst gesuchten Begriffe vorhält (die erste Seite vielleicht sogar komplett) wäre natürlich nicht schlecht. Aber es würde wahrscheinlich auch nix rausreißen. Deshalb erstmal die Suche sorgfältig und ohne große Spielereien aufbauen und stabil bekommen. Wer dann noch Lust und Zeit hat, kann sich ja daran versuchen.
so short
Christoph Zurnieden
Hi
Ich meinte die häufigsten 65000 Suchbegriffe, das sind ja die Fachbegriffe.
Soviele werden das insgesamt kaum sein, vemutlich nur ein paar Tausend, wenn überhaupt, die signifikant oft nachgefragt wurden.
Ganz deiner Meinung, höchstwahrscheinlich die alte 10% zu 90%
Regel. (da gabs auch so ne empirische Untersuchung von Linguisten (?), das Sprachen allgemein dieser Regel genügen)
2^16 war nur ne Hausnummer mit der sich gut rechen läßt...
Aber wahrscheinlich macht alleine schon ein Cache der letzten Abfragen einer Session auch sehr viel sinn, weil die Querys eines Nutzers oft sukzessive wachsen.
Aber das ist ja auch nicht das Problem, das Ärgernis liegt darin, das da täglich verschieden drauf geantwortet werden muß, denn täglich wird das Archiv geupdated.
Wieso, es reicht doch die Referenz auf die Liste der Postings eines Begriffes zu cachen, schließlich müssen diese wowieso ständig geupdatet werden...
Vermutlich denke ich mal wieder zu sehr in meinem Modell, da Daniela keine Listen von Referenzen baut.
eher nicht, ich finde die alte Suche aktuell schon performant genug.
Wenn wirklich jeder vorher erstmal suchen würde, der hier eine Frage stellt, wäre sie schon jetzt am Ende. Sie war überhaupt nicht für solch einen Andrang vorgesehen.
Ja aber man muss für eine Zukunftsprognose den Postinganstieg in Relation mit dem Mooreschem Gesetz sehen. Und ich sehe mittlerweile eine Abflachung der Archivkurve.
Das sie überhaupt so lange durchgehalten hat, läßt einen den Hut vor dem Programmierer ziehen!
Dito :) BTW auch an die Programmierer der RegExp die als hocheffektive Automaten realisiert wurden.
Nicht rausreden, machen. Wenn's dann nach sorgfältiger Prüfung für zu leicht befunden wurde - tja, dann hast Du eben im schlimmstem Fall eine schöne Fingerübung hinter Dir. Und das ist schließlich nichts Schlechtes!
Ich halte es aus Projektsicht nicht für sinnvoll Technologien zu mischen, der Ansatz über eine DB zu gehen ist schon vom Total Cost of Ownership her korrekt, insbesondere bei der Wartung hochspezialisierter Algorithmen.
Alleine was mir zu denken gibt, sind die Probleme aus den Hardwareanforderungen. Mein Credo ist es das der Algo der Maschine anzupassen sein muss und nicht umgekehrt...
Als "genestet" kann man die eigentlich nicht unbedingt beschreiben? Aber gut, ich erklär's einfach mal in groben Zügen und Du sagst dann, ob Du genau das gemeint hast oder nicht:
Wenn beim Hashing eine Kollision stattfindet kann man da grundsätzlich auf zwei verschiedene Arten drangehen:
- ein anderes unbelegtes Loch suchen
- alles in ein Loch quetschen
Letzteres, hatte auch bereits den Fachbegriff "Offenes Hashing" dafür refrenziert http://de.wikipedia.org/wiki/Hash-Funktion#Offenes_Hashing
aber das geht in diesem Thread auch schon mal verloren.
Die unmengen an Hashfkt habe ich schon als Bottleneck erkannt, bin davon ausgegangen dass sie einfach nur selten gebraucht werden.
Warum gehst Du davon aus?
weil ich zum sekundären Hash die Information zur Hashfkt mit ablegen muss, das kann mitunter teuer werden.
OK, angenommen ich nehme eine für die deutsche Sprache gute Hashfkt die 32 Bit zB \xABCD liefert.
Das sind nur 16 Bit.
Aber egal, ich weiß, was Du meinst.
Ahhh, toucher, dann hast du wenigstens deine "Gigabit-Schlappe " gerächt. ;)
Wenn ich die oberen 16 bits \xAB nehme könnte ich locker eine Tabelle im RAM adressieren.
Kommt auf die Architektur und das OS an. Normalerweise sind aber 32 bzw 64 Bit dazu nötig.
Aber auch hier: egal, ich weiß, was Du meinst.
ach gottchen, das bisschen shift und maskieren krieg ich hin.
Damit hättest Du dann rein theoretisch 2^16*2^16 = 2^(16+16) = 2^32 Eintragsmöglichkeiten. Nix gewonnen. Eher etwas verloren, denn die Tabelle im Ram ist doppelt so groß, wie Du vermutest, also bleiben am Ende nur noch 2^31 Eintragsmöglichkeiten mit nutzbaren Daten über.
wieso ist die Tabelle im RAM doppelt so groß wie vermutet?
Im übrigen ist 16 nur ne Hausnummer die korrigiert werden kann.
Noch ein Problem: die Hashfunktion müßte bijektiv sein bzw Du müßtest den Suchbegriff mitgeben.
Hä? Für einen Hash brauche ich den Suchbegriff doch immer, um auf Kollision zu checken, oder?
In der RAM-Tabelle könnte dann auch in jeder Zelle, - quasi als Caching - die wichtigsten/häufigsten Schlüssel
aus der Platten-Tabelle liegen, um einen teuren Zugriff zu vermeiden.Nein, das bringt nur 0,0000irgendwas% plus oder minus Gewinn.
Ein Caching müßte schon vollständig sein.
Was meinst du mit vollständig? Wenn ich erst einen extra Cache
durchsuche ist das eine Suche mehr, die jedesmal zu buche
schlägt. Bei dieser Methode fällt der Cachewert während der einen Suche selbst quasi als Abfallprodukt an.
"Obere" und "untere" Bits heißen auch "most signifcant bit(s)" respektive "least significant bit(s)" und das nicht ohne Grund.
Grummel, letztendlich ist es egal wieviele und welche Bits ich für die eine RAM-Tabelle nehme. Wir haben einen 32 dimensionalen Würfel den wir beliebig drehen und projezieren können.
Du kannst so einen Hash nicht einfach in der Mitte teilen, das haut einfach nicht hin. Die Entropie des Hashwertes steckt im _gesammtem_ Hashwert, Teile davon sind höchst unterschiedlich "zufällig".
Die Hashfkt soll es aber erlauben. Jetzt mal ein theoretischer Ansatz, hätte ich einen idealen Zufallsgenerator (z.B. Schrödingers Katze ;) mit dem ich die Werte der Hashfkt einmal ermittle und in eine Tabelle schriebe -ohne Duplikate-, dann hätte diese Fkt so ziemlich die gewünschte Eigenschaft über alle Bits zufälig zu sein.
OK, theoretisch, aber über ne rekursive Definition muss sich doch sowas basteln lassen, oder !?!
Sieht man am besten mit einem LKG-Zufallsgenerator.
---snip---
#ifndef _ISOC99_SOURCE
#define _ISOC99_SOURCE
#endif ...
och bitte, die Source einer ungeeigneten Hashfkt schließt aber nicht die Existenz einer geigneten aus. (Sorry, bis ich den Code durchgearbeit habe, inklusive Theorie, ist der Thread im Archiv, deswegen später mehr ...)
Mit anderen Worten, wenn die ursprüngliche Hashfkt mit 32 Bit eine gute Verteilung hat, dann eigentlich auch eine abgeleitete Hashfkt mit weggestrichenen Bits.
Nein, eben nicht, siehe oben.
OK allgemein nicht ...
Knackpunkt wäre es also eine gute Hashfkt mit 32 Bit für die Selfsprache zu finden.
Oder irre ich mich?Du suchst also die perfekte Welle^WHashfunktion? Glaube nicht, das Dir das viel nützt. Das meine ich wörtlich: ich glaube nicht, das es _viel_ nützt. Der Aufwand steht in rein gar keinem Verhältnis zum Nutzen.
Perfekt ist wohl zuviel verlangt, eine die die Eigenschaften der Sprache nutzt wäre schon nett.
Du könntest natürlich auch mit n-grammen arbeiten. Dann arbeitest Du aber nicht nur mit riesigen Mengen, die Du erstmal mit ein paar Regeln (welchen Regeln?) kleiner bekommen mußt, dazu kommt noch, das die Worte jedesmal gesplittet werden müssen.
Ok jetzt mal wieder ne Idee ins blaue: Man zerlegt ein Wort in seine ersten 2 Silben und den Rest. Für den Anfangsteil berechnet man einen möglichst kompakten Code C wie bei Huffman
über die Silbenwahrscheinlichkeit, sodass möglichst viele Bits für die Codierung des Restes verbleiben (wäre bikjektiv). Den Rest codiert man mittels einer adequaten Hashfkt H1.
Das hätte den Vorteil das je wahrscheinlicher Wörter mit 2 bestimmten Anfangssilben sind, umso mehr Bits für die Hashfkt zur Verfügung stehen, sodass möglichst wenige Kollisionen entstehen können.
Wir erhalten also eine Hashfkt H2=C(S1S2)+ H1(Sn).
... ahh essen ruft ...
Tschau
rolf
Hi,
Aber wahrscheinlich macht alleine schon ein Cache der letzten Abfragen einer Session auch sehr viel sinn, weil die Querys eines Nutzers oft sukzessive wachsen.
Was für eine Session?
Es wäre auch nicht günstig, ausgerechnet die letzten Abfragen einer solchen Session zu cachen, da sie gegen Ende hin meistens immer feiner werden, spezialisierter also. Caching lohnt aber nur, wenn das Gecachte auch oft verlangt wird. Eine Spezialabfrage mit Datum, Autor und Phrase, wenn ich das mal etwas übertreiben darf, kommt aber eher selten vor, ein Caching würde nur Platz verschwenden.
Aber das ist ja auch nicht das Problem, das Ärgernis liegt darin, das da täglich verschieden drauf geantwortet werden muß, denn täglich wird das Archiv geupdated.
Wieso, es reicht doch die Referenz auf die Liste der Postings eines Begriffes zu cachen, schließlich müssen diese wowieso ständig geupdatet werden...
Ja, genau und darin würde auch eine Gelegenheit zur Optimierung liegen: eine gut passende Strategie zum Indexupdate zu finden. Was Du cachen möchtest liegt aber bereits komplett im RAM und muß nicht weiter optimiert werden. Meine Wortliste hat 1.549.146 Einträge (zwar lowercase, aber aus 3 Sprachen und dazu noch den üblichen Verdächtigen) und ist gerade mal knapp 18 MiB groß. Alles in eine luxuriöse DB-Tabelle gepackt macht rund 100-150 MiB. Das ist nicht sonderlich viel.
Vermutlich denke ich mal wieder zu sehr in meinem Modell, da Daniela keine Listen von Referenzen baut.
Weiß man nicht, bevor man's nicht gesehen hat.
Ja aber man muss für eine Zukunftsprognose den Postinganstieg in Relation mit dem Mooreschem Gesetz sehen. Und ich sehe mittlerweile eine Abflachung der Archivkurve.
So sah das nach den ersten drei Jahren auch aus. Geht man davon aus, ist in diesem Jahr eine Steigerung um das Viereinhalbfache im Vergleich zu 2004 zu erwarten.
Das sie überhaupt so lange durchgehalten hat, läßt einen den Hut vor dem Programmierer ziehen!
Dito :) BTW auch an die Programmierer der RegExp die als hocheffektive Automaten realisiert wurden.
Du warst nie im Perlcode, oder?
Aber solltest Du auch eigentlich direkten Kontakt vermeiden, zumindest zum Altem. Mein Augenzucken und die grauen Strähnen im Bart habe ich erst seitdem.
Ich halte es aus Projektsicht nicht für sinnvoll Technologien zu mischen, der Ansatz über eine DB zu gehen ist schon vom Total Cost of Ownership her korrekt, insbesondere bei der Wartung hochspezialisierter Algorithmen.
"Nu' hann 'sch Kopping!"[1], wie der Rheinländer bei solchen Anhäufungen sinnfreier Buzzwords gerne zu sagen pflegt.
Laß es bitte. Danke.
Alleine was mir zu denken gibt, sind die Probleme aus den Hardwareanforderungen. Mein Credo ist es das der Algo der Maschine anzupassen sein muss und nicht umgekehrt...
Dann sag' das mal Microsoft.
Nein, mittlerweile ist Hardware deutlich billiger geworden als Arbeitszeit. Es sieht zwar so aus, als ob da Änderungen gesucht würden, aber im Augenblick ist es noch so.
Wenn beim Hashing eine Kollision stattfindet kann man da grundsätzlich auf zwei verschiedene Arten drangehen:
- ein anderes unbelegtes Loch suchen
- alles in ein Loch quetschen
Letzteres, hatte auch bereits den Fachbegriff "Offenes Hashing" dafür refrenziert http://de.wikipedia.org/wiki/Hash-Funktion#Offenes_Hashing
aber das geht in diesem Thread auch schon mal verloren.
Hier geht nix verloren, hier wird _alles_ archiviert.
Es sei denn, es ginge mal etwas verloren.
Wenn Du also 2) meintest, dann habe ich Dich wohl mißverstanden. Allerdings verstehe ich Dein Begehr dann gar nicht mehr, das macht bei 2) doch rein gar keinen Sinn? Ja, ist eigentlich sogar kontraproduktiv?
Die unmengen an Hashfkt habe ich schon als Bottleneck erkannt, bin davon ausgegangen dass sie einfach nur selten gebraucht werden.
Warum gehst Du davon aus?
weil ich zum sekundären Hash die Information zur Hashfkt mit ablegen muss, das kann mitunter teuer werden.
Und die werden dann nur selten gebraucht, weil sie teuer sind? Nein, so ganz verstehe ich es noch nicht.
Teuer wäre es auch nicht, da es durchaus Methoden gäbe, viele verschieden Hashfunktionen aufgrund eines kurzen Seeds zu bauen.
Aber ich glaube, so langsam komme ich dahinter:
Du möchtest also gerne die sonst üblichen Linked Lists, die bei der Methode 2) entstehen durch eine weitere Hashtabelle ersetzen. Und wenn es bei dieser dann Kollisionen gibt, wiederum eine Hashtabelle anstatt einer Linked List nehmen und das ad finitum acerbum?
Nä, das wäre ja völlig beklopft, das kann's wohl doch nicht gewesen sein?
Damit hättest Du dann rein theoretisch 2^16*2^16 = 2^(16+16) = 2^32 Eintragsmöglichkeiten. Nix gewonnen. Eher etwas verloren, denn die Tabelle im Ram ist doppelt so groß, wie Du vermutest, also bleiben am Ende nur noch 2^31 Eintragsmöglichkeiten mit nutzbaren Daten über.
wieso ist die Tabelle im RAM doppelt so groß wie vermutet?
Du erzeugst einen Pointer auf eine Stelle im RAM in der _was_ ist? Ein weiterer Pointer? Wohin? Auf eine Stelle auf der Platte? Wozu dann der Umweg? Es ist also schon etwas mehr Information nötig, diesen Umweg plausibel zu machen. Z.B. etwas Metainformation. Und 16 Bit + 1 Bit sind 17 Bit. Kleinste Größe auf den heute üblichen Architekturen sind 32/64 Bit, also ist die Tabelle doppelt so groß wie vermutet bzw ganz überflüssig.
Im übrigen ist 16 nur ne Hausnummer die korrigiert werden kann.
Hilft hier auch nicht mehr.
Noch ein Problem: die Hashfunktion müßte bijektiv sein bzw Du müßtest den Suchbegriff mitgeben.
Hä? Für einen Hash brauche ich den Suchbegriff doch immer, um auf Kollision zu checken, oder?
Nein, warum das denn?
Ein Caching müßte schon vollständig sein.
Was meinst du mit vollständig? Wenn ich erst einen extra Cache
durchsuche ist das eine Suche mehr, die jedesmal zu buche
schlägt. Bei dieser Methode fällt der Cachewert während der einen Suche selbst quasi als Abfallprodukt an.
Ähm .. nein, so meinte ich das nicht:
Die Information im Cache sollte vollständig sein, z.B. die erste Seite einer Suche nach dem Wort XYZ. Welche Worte gecached werden sollen kann eine empirische Untersuchung über die Häufigkeit der Suchen ermitteln, wieviel liegt am freiem Plattenplatz. Diese Seite ist am besten schon fertig formatiert und gzipped, "ready to go" sozusagen. Ob etwas gecached ist sagt Dir ein Bloomfilter. Dieser Bloomfilter kann sogar per Javascript in die Formularseite eingebunden werden, sodaß für jeden Sucher, der JS eingeschaltet hat dieser Vorgang auf dem Server schonmal überflüssig wird, er bekommt die Antwort "ist gecached | nicht gecached" schon frei Haus geliefert.
"Obere" und "untere" Bits heißen auch "most signifcant bit(s)" respektive "least significant bit(s)" und das nicht ohne Grund.
Grummel, letztendlich ist es egal wieviele und welche Bits ich für die eine RAM-Tabelle nehme. Wir haben einen 32 dimensionalen Würfel den wir beliebig drehen und projezieren können.
Nein, eben nicht. Das ist ja eines der Probleme auf das Du stößt, wenn Du Hashe so willkürlich teilst: die Verteilung der einzelnen Teile entspricht nicht Deinen Wünschen und Vorstellungen. Besonders wenn die Hashtabellen gut gefüllt sind beginnt der Ärger.
Die Hashfkt soll es aber erlauben.
Ja, damit hättest Du dann aber fast schon kryptographisch sichere Hashfunktionen, soviel Aufwand wäre es, jedes Bit mit möglichst gleichem Entropiewert zu belegen.
Jetzt mal ein theoretischer Ansatz, hätte ich einen idealen Zufallsgenerator (z.B. Schrödingers Katze ;)
Da reicht schon thermisches Rauschen. Deine Soundkarte ist da gerne behilflich. Aber selbst da hast Du Ärger mit der Entropieverteilung. Die AD-Wandler der gängigen Soundkarten sind nunmal nicht so sonderlich und Du hast schwer zu kämpfen, daraus etwas gutes zu machen.
mit dem ich die Werte der Hashfkt einmal ermittle und in eine Tabelle schriebe -ohne Duplikate-, dann hätte diese Fkt so ziemlich die gewünschte Eigenschaft über alle Bits zufälig zu sein.
Das, was Pearson vorschlug, ja.
OK, theoretisch, aber über ne rekursive Definition muss sich doch sowas basteln lassen, oder !?!
Wenn etwas rekursiv ist, ist es automatisch nicht mehr zufällig. Du meinst also etwas anderes, was bitte?
Sieht man am besten mit einem LKG-Zufallsgenerator.
[...]
och bitte, die Source einer ungeeigneten Hashfkt schließt aber nicht die Existenz einer geigneten aus.
Das war ein Beipiel, um Dir den Unterschied zwischen MSB und LSB sichtbar zu machen, mehr nicht.
(Sorry, bis ich den Code durchgearbeit habe, inklusive Theorie, ist der Thread im Archiv, deswegen später mehr ...)
Nein, der hier landet so schnell nicht im Archiv, das glaube ich weniger. Der dürfte noch bis zm Wochenende oder zumindest kurz davor hier rumliegen.
Wenn ihn keiner rausschmeißt heißt das natürlich, aber _das_ würde mich dann doch ein wenig wundern.
Mit anderen Worten, wenn die ursprüngliche Hashfkt mit 32 Bit eine gute Verteilung hat, dann eigentlich auch eine abgeleitete Hashfkt mit weggestrichenen Bits.
Nein, eben nicht, siehe oben.
OK allgemein nicht ...
Ich weiß nicht, ob RMD160, SHA1 o.ä. kryptographisch sichere Hashfunktionen eine Ausnahme darstellen, glaube es aber eher nicht.
Perfekt ist wohl zuviel verlangt, eine die die Eigenschaften der Sprache nutzt wäre schon nett.
Eigenschaft der Eingangsprache: Strings variabler Länge.
Wenn Du jetzt noch _irgendeine_ weitere Eigenschaft findest, die sich in eine Hashfunktion integrieren läßt?
Du könntest natürlich auch mit n-grammen arbeiten. Dann arbeitest Du aber nicht nur mit riesigen Mengen, die Du erstmal mit ein paar Regeln (welchen Regeln?) kleiner bekommen mußt, dazu kommt noch, das die Worte jedesmal gesplittet werden müssen.
Ok jetzt mal wieder ne Idee ins blaue: Man zerlegt ein Wort in seine ersten 2 Silben und den Rest.
Was sind Silben, was ist Rest?
Für den Anfangsteil berechnet man einen möglichst kompakten Code C wie bei Huffman
über die Silbenwahrscheinlichkeit, sodass möglichst viele Bits für die Codierung des Restes verbleiben (wäre bikjektiv). Den Rest codiert man mittels einer adequaten Hashfkt H1.
Meinst Du nicht auch, das Du in der Zeit, wo Du das alles berechnest auch einfach die DB gefragt haben könntest?
Sinnvolle Optimierungen sind von der Idee her stets einfach, ansonsten meist Mikrooptimierung.
Die Implementation selber kann dann durchaus etwas komplexer sein. Beipiel Komprimierung: Die Idee war, das englischer Text viele Redundanzen enthält (7-Bit Encodierung bei Binärarchitekturen usw) und die doch entfernt werden könnten, die Implementation von Huffman war dann zwar etwas komplexer, aber auch allgemeiner.
... ahh essen ruft ...
Schwein gehabt, was?
so short
Christoph Zurnieden
[1] Zu deutsch: "Nun habe ich Kopfweh!"
Hi,
da ich grade eine halbe stunde tipparbeit verloren habe antworte ich mal in mehreren Posts:
Aber wahrscheinlich macht alleine schon ein Cache der letzten Abfragen einer Session auch sehr viel sinn, weil die Querys eines Nutzers oft sukzessive wachsen.
Ich meinte ein zusätzliche Caching der Abfragen der letzten x Minuten, da viele ihre Queries sukzesive anpassen, bis sie ausreichend wenige Treffer haben.
Aber ich glaube, so langsam komme ich dahinter:
Du möchtest also gerne die sonst üblichen Linked Lists, die bei der Methode 2) entstehen durch eine weitere Hashtabelle ersetzen. Und wenn es bei dieser dann Kollisionen gibt, wiederum eine Hashtabelle anstatt einer Linked List nehmen und das ad finitum acerbum?
soll heißen "bis zum bitteren Ende" ???
Nä, das wäre ja völlig beklopft, das kann's wohl doch nicht gewesen sein?
Jein, in der 2. Stufe ist Schluss. Man kann kein beliebig großes Hash im RAM halten, deswegen soll die erste Stufe H im RAM liegen und die der 2. Stufe K(H) auf der Platte, die für jede Zelle von H seine Kollisionen enthalten. Zahlenbeispiel: Hat H 16bit ~ 64K Zellen, brauche ich auch 65536 sekundäre Hashes K auf der Platte.
Jetzt suche ich ein Wort W.
Fall 1 (Treffer): Ist das Schlüsselwort von S(H(W))=W habe ich gewonnen und erhalte eine Liste L(H(W)) aller Postings die W enthalten.
Fall 2 (Kollision): Ich muss ich auf die Platte zugreifen und suche W im zugehörigen Hash K(H(W)).
Damit sich das lohnt darf es in möglichst wenigen Fällen Zugriffe auf die Platte geben, deswegen sollten die Treffer S(H) gleich dem jeweils meistgewünschtem Schlüssel in den zugehörigen Subhashes K(H) sein, was dann einem Cashing nahekommt.
Ressourcenanfoderung:
1. Während die größe des Hashes H fix ist, und sich nach verfügbarem RAM richet, können die K(H) auf der Platte wachsen. (letzteres IMHO langsamer als eine relationale DB wächst)
2. (Posting) Für jedes neue Posting müssen pro enthaltenem Wort die Liste L(W) um die Refernez auf das neue Posting erweitert werden.
3. (Neuwörter) Kommt ein neues Wort hinzu, muss es auch in im zugehörigen K auf der Platte eingetragen werden.
4. (Reorganisation) Wenn ich dich recht verstanden habe sollten 25% der Zellen eines Hashes frei sein, sind also mehr als 75% eines K belegt, ersetzt man ihn durch einen doppelt so großen. Diese Reorganisation dürfte aber sehr selten vorkommen, weil das Vokabular des Forums nicht so schnell wächst.
5. (Plattenbedarf): Von 4. ausgehend brauche ich im Schnitt 25% mehr Platz für die K-Hashes als Einträge da sind. Für die L-Listen schätze ich weniger als ein Viertel des Vollindexes ein, insgesamt vielleicht 250 MB.(?)
Wichtig ist das die Hashfkt in H eineseits und den Ks unabhängig möglichst unabhängig sein muss, damit es keine unnötigen Kollisionen gibt (wären sie identisch gäbs den GAU). Der Ansatz über eine 32bit Fkt die ich in 2 kleinere zerlege war ein Versuch das zu garantieren (in diesem Fall wäre auch die Reorganisation eines K sehr billig)
Ich hoffe das grobe Konzept einigermaßen rübergebracht zu haben, natürlich steckt da noch Verbesserungspotential drinnen.
Insbesondere ist wichtig wie am besten Daten auf der Platte organisiert und darauf zugegriffen wird, ich denke die DB arbeitet da schon ziemlich effizient.
... ahh essen ruft ...
Schwein gehabt, was?
ne Grünkrams... :)
Bye
rolf
Hi,
da ich grade eine halbe stunde tipparbeit verloren habe antworte ich mal in mehreren Posts:
Nein, da geht nix verloren, wenn da steht "Das war jetzt etwas zu lang". Aber wenn man dann etwas zu hektisch reagiert ist natürlich alles weg. Macht aber nix, passiert mir auch hin und wieder. Ist auch ganz gut gegen Abschweifungen.
Aber wahrscheinlich macht alleine schon ein Cache der letzten Abfragen einer Session auch sehr viel sinn, weil die Querys eines Nutzers oft sukzessive wachsen.
Ich meinte ein zusätzliche Caching der Abfragen der letzten x Minuten, da viele ihre Queries sukzesive anpassen, bis sie ausreichend wenige Treffer haben.
Du verfügst über eine Statistik der Forumssuche in derart hoher Auflösung? Kommen da andere auch ran?
Aber ich glaube, so langsam komme ich dahinter:
Du möchtest also gerne die sonst üblichen Linked Lists, die bei der Methode 2) entstehen durch eine weitere Hashtabelle ersetzen. Und wenn es bei dieser dann Kollisionen gibt, wiederum eine Hashtabelle anstatt einer Linked List nehmen und das ad finitum acerbum?soll heißen "bis zum bitteren Ende" ???
Ja.
Ist die Rache eines Humanisten am Denglisch.
Nä, das wäre ja völlig beklopft, das kann's wohl doch nicht gewesen sein?
Jein, in der 2. Stufe ist Schluss. Man kann kein beliebig großes Hash im RAM halten, deswegen soll die erste Stufe H im RAM liegen und die der 2. Stufe K(H) auf der Platte, die für jede Zelle von H seine Kollisionen enthalten. Zahlenbeispiel: Hat H 16bit ~ 64K Zellen, brauche ich auch 65536 sekundäre Hashes K auf der Platte.
Das ist nicht sonderlich sinnvoll, da die zweite Hashtabelle ebenfalls unter Kollisionen leiden wird. Wie regelst Du die?
BTW: Du benötigst für den ganzen Schisselamäng nur eine einzige ordentliche Hashfunktion, nicht mehr. Auch wenn die Hashtabellen optisch als zusammengehörig erscheinen, so sind sie doch völlig unabhängig und Du kannst einen einmal mühselig errechneten Hashwert vollständig wiederverwenden.
Jetzt suche ich ein Wort W.
Fall 1 (Treffer): Ist das Schlüsselwort von S(H(W))=W habe ich gewonnen und erhalte eine Liste L(H(W)) aller Postings die W enthalten.
Woher weißt Du das?
Dafür mußt Du den Hashwert ausrechnen. Der zeigt auf ein Loch, darin ist entweder nix oder es ist belegt. Im Falle der Suche ist die Belegung wichtig. Um jedoch herauszufinden, ob es sich um eine Kollision handelt, mußt Du das Wort mit dem Inhalt des Loches vergleichen. Also muß im Loch auch das Wort sein. Ist es belegt aber nicht vom gesuchtem Wort ist es eine Kollision:
Fall 2 (Kollision): Ich muss ich auf die Platte zugreifen und suche W im zugehörigen Hash K(H(W)).
I/O ist als genauso teuer anzusehen, wie ein DB-Anfrage. Dieser Teil der Übung ist also zweckfrei, direkte Anfage an DB wäre günstiger.
Obige Hashtabelle wäre sehr günstig, wenn alle Anfragen Einwortanfragen wären. Bei Mehrwortanfragen wäre jedes Wort einzeln zu prüfen. Gut, das ist seltenst viel, das würde sich wahrscheinlich auch noch lohnen. Phrasensuche wäre aber schon schwieriger.
Zudem ist diese Technik auf die Serverseite beschränkt.
Ein Bloomfilter zwischen Eingabe und Cache macht da deutlich mehr Sinn.
- Während die größe des Hashes H fix ist, und sich nach verfügbarem RAM richet, können die K(H) auf der Platte wachsen. (letzteres IMHO langsamer als eine relationale DB wächst)
Nein, können sie nicht. Du kannst sie nur statsisch einrichten. Das aber natürlich nach Bedarf: wenn an der Stelle noch nichts kollidiert ist, besteht natürlich auch noch kein Bedarf.
- (Posting) Für jedes neue Posting müssen pro enthaltenem Wort die Liste L(W) um die Refernez auf das neue Posting erweitert werden.
Wie ist dies Liste implementiert?
- (Neuwörter) Kommt ein neues Wort hinzu, muss es auch in im zugehörigen K auf der Platte eingetragen werden.
Klar, wenn man bei der Suche auf ein leeres Loch stößt, wird eingetragen. Aber das ist glaube ich so Usus bei Hastabellen.
- (Reorganisation) Wenn ich dich recht verstanden habe sollten 25% der Zellen eines Hashes frei sein, sind also mehr als 75% eines K belegt, ersetzt man ihn durch einen doppelt so großen.
Ja, das ist die übliche und wohlerprobte Vorgehensweise.
Diese Reorganisation dürfte aber sehr selten vorkommen, weil das Vokabular des Forums nicht so schnell wächst.
Davon kannst Du nicht ausgehen, eher davon ds es zwischenzeitlich heftige Sprünge geben wird. Es muß nur eine andere Programmiersprache modern werden, ja, nur ein kurzes Listing in einer anderen Sprache würde einen guten Hub ergeben.
- (Plattenbedarf): Von 4. ausgehend brauche ich im Schnitt 25% mehr Platz für die K-Hashes als Einträge da sind. Für die L-Listen schätze ich weniger als ein Viertel des Vollindexes ein, insgesamt vielleicht 250 MB.(?)
Kein Ahnung, könnte aber hinkommen.
Wichtig ist das die Hashfkt in H eineseits und den Ks unabhängig möglichst unabhängig sein muss, damit es keine unnötigen Kollisionen gibt (wären sie identisch gäbs den GAU). Der Ansatz über eine 32bit Fkt die ich in 2 kleinere zerlege war ein Versuch das zu garantieren (in diesem Fall wäre auch die Reorganisation eines K sehr billig)
Nein, Du brauchst nur eine einzige Hashfunktion, da alle Hastabellen in Deinem Gedankenexperiment unabhängig sind.
Ich hoffe das grobe Konzept einigermaßen rübergebracht zu haben,
Also um ehrlich zu sein ...
Wie wäre es mit einem kurzem Proof-of-Concept?
natürlich steckt da noch Verbesserungspotential drinnen.
Insbesondere ist wichtig wie am besten Daten auf der Platte organisiert und darauf zugegriffen wird,
Das solltest Du dem Dateisystem überlassen, die modernen wie z.B. ReiserFS sind da kaum zu überbieten. Du kannst einafch schreiben, den Rest übernimmt das FS.
ich denke die DB arbeitet da schon ziemlich effizient.
Eben.
so short
Christoph Zurnieden
Hi
Aber wenn man dann etwas zu hektisch reagiert ist natürlich alles weg.
so wars.
Du verfügst über eine Statistik der Forumssuche in derart hoher Auflösung? Kommen da andere auch ran?
hehehe ich extrapoliere da mein verhalten, kann natürlich auch sein das 90% der Leute auf anhieb perfekte Queries reinhauen und sofort zufrieden sind... (ich glaubs nicht)
Das ist nicht sonderlich sinnvoll, da die zweite Hashtabelle ebenfalls unter Kollisionen leiden wird. Wie regelst Du die?
So wie du es gewohnt bist als geschlossenen Hash. Ist die Zelle (falsch) belegt sucht eine kluge Methode ne neue.
BTW: Du benötigst für den ganzen Schisselamäng nur eine einzige ordentliche Hashfunktion, nicht mehr. Auch wenn die Hashtabellen optisch als zusammengehörig erscheinen, so sind sie doch völlig unabhängig und Du kannst einen einmal mühselig errechneten Hashwert vollständig wiederverwenden.
??? na eben nicht! Seien h=k die zugehörigen Fkten, für gleichmächtige Hashes H,K. Die k(W) berechne ich ja jeweils nur für die Wi der Kollisionen in H, d.h. h(W1)=h(W2). Ich hätte dann in K einen GAU von Kollision, wo alle k(Wi) alle auf den gleichen Wert abgebildet werden. Die Fkten müssen sehr wohl unabhängig sein, und zwar bewiesenermaßen (!) um performant zu sein.
Jetzt suche ich ein Wort W.
Fall 1 (Treffer): Ist das Schlüsselwort von S(H(W))=W habe ich gewonnen und erhalte eine Liste L(H(W)) aller Postings die W enthalten.
Woher weißt Du das?
Auf Assemblerebene? Belegte Zellen enthalten einen Pointer auf eine Datenstruktur der Form (Schlüsselwort, *Post1, *Post2, *Post3,...)
Fall 2 (Kollision): Ich muss ich auf die Platte zugreifen und suche W im zugehörigen Hash K(H(W)).
I/O ist als genauso teuer anzusehen, wie ein DB-Anfrage. Dieser Teil der Übung ist also zweckfrei, direkte Anfage an DB wäre günstiger.
kann sein, aber die DB braucht ja auch GB-weise Metadaten, sonst würd sie ja schon laufen. Ausserdem bin ich ziemlich sicher das die DB mit ihrer Binären Suche viel häufiger auf die Platte zugreift.
Obige Hashtabelle wäre sehr günstig, wenn alle Anfragen Einwortanfragen wären.
Einwortanfragen? Du meinst wenn der Query nur aus einem Wort besteht?
Bei Mehrwortanfragen wäre jedes Wort einzeln zu prüfen. Gut, das ist seltenst viel, das würde sich wahrscheinlich auch noch lohnen. Phrasensuche wäre aber schon schwieriger.
Wieso seltenst? Die Schnittmenge der Postinglisten muss halt gebildet werden. (gleich kommt sowas wie geordnete Listen dafür nicht optimal sind ... geschenkt ;-)
Phrasensuche wäre aber schon schwieriger.
Natürlich, hier gehts nur um einzelne ganze Wörter.
Phrasensuche reicht im ersten Ansatz, so wie Daniela es auch plant.
Zudem ist diese Technik auf die Serverseite beschränkt.
Klar einen zweistufigen Hash brauche ich in JS nicht, weil dort sowieso alles (transparent) im RAM ist.
...obwohl - perverse Ideeee - eine Anwendung wäre dann die K-Hashes per HTTP in einem Popup anzufordern. *fg* Dann könnte man die Selfsuche auch in JS realisieren hehehe...
Ein Bloomfilter zwischen Eingabe und Cache macht da deutlich mehr Sinn.
Hab gerade mal bloomfilter http://en.wikipedia.org/wiki/Bloom_filterüberflogen. Durchaus faszinierend, aber wozu willst du den hier einsetzen? Teilstringsuche???
(im Vertrauen, das alles hab ich nie studiert, Theorie der Hashes kenn ich aus nem CT-Artikel vor 5 Jahren, auch Herrn Pearson musste ich erst nachschlagen, lerne momentan gut dazu :)
- (Posting) Für jedes neue Posting müssen pro enthaltenem Wort die Liste L(W) um die Refernez auf das neue Posting erweitert werden.
Wie ist dies Liste implementiert?
Erstmal trivial aufsteigend linear sortiert. Brächte Vorteile wenn man nur die Differenzen abspeichern muß, desto mehr Listen passen ins RAM.
Diese Reorganisation dürfte aber sehr selten vorkommen, weil das Vokabular des Forums nicht so schnell wächst.
Davon kannst Du nicht ausgehen, eher davon ds es zwischenzeitlich heftige Sprünge geben wird. Es muß nur eine andere Programmiersprache modern werden, ja, nur ein kurzes Listing in einer anderen Sprache würde einen guten Hub ergeben.
Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden.
Also ich halt jede Wette das der Zuwachs an Vokabeln des Forums über die Jahre abgeflacht ist.
Nein, Du brauchst nur eine einzige Hashfunktion, da alle Hastabellen in Deinem Gedankenexperiment unabhängig sind.
Eben nicht, s.o.
Ich hoffe das grobe Konzept einigermaßen rübergebracht zu haben,
Also um ehrlich zu sein ...
Wie wäre es mit einem kurzem Proof-of-Concept?
Nur der Algo schnell in JS realisiert wie oben beschrieben?
Hmm das könnte ich sogar gut recyclen...
Gut, ich bräuchte 2 Sätze Hashfkten zu einer vorgegebenen Bitlänge i, h_i, und k_ij wobei zu jeder bitlänge i,j die h_i und k_ij paarweise unabhängig sind.
(Für den PoC reicht auch ein Paar h, k unabhängig und Vokabular kleiner 2^(i+j))
Wenns die gibt, dann klappts auch. (ich könnt jetzt suchen, aber du schüttelst das doch aus dem Ärmel, oder :)
Insbesondere ist wichtig wie am besten Daten auf der Platte organisiert und darauf zugegriffen wird,
Das solltest Du dem Dateisystem überlassen, die modernen wie z.B. ReiserFS sind da kaum zu überbieten. Du kannst einafch schreiben, den
Rest übernimmt das FS.
Wenn ich damit performant auf Zellen der K-Hashes zugreifen kann, gerne.
ich denke die DB arbeitet da schon ziemlich effizient.
Eben.
ja aber bei euren Worstcase-Szenarien geht die DB viel schneller in die Knie. Die hier skizierte Methode kannst du auf Servern mit jedem RAM/HD-Szenario realisieren, der auch Michaels Vollindex schlucken kann.
Die Bäume einer DB sind doch auf viel generellere Anforderungen hin optimiert, die hier gar nie auftreten werden. Z.B. müssen hier nicht täglich Millionen Postings eingetragen werden oder Rollbacks gefahren werden und und und ...
Tschau
Rolf
Hi Rolf
kann sein, aber die DB braucht ja auch GB-weise Metadaten, sonst würd sie ja schon laufen. Ausserdem bin ich ziemlich sicher das die DB mit ihrer Binären Suche viel häufiger auf die Platte zugreift.
a) Eine DB benutzt _nie_ binäre Bäume, das wäre idiotisch, sie benutzt balancierte Bäume.
b) Könnte ich genauso gut einen Hash-Index benutzen:
http://www.postgresql.org/docs/7.4/interactive/indexes-types.html
Gruss Daniela
Hi Daniela
kann sein, aber die DB braucht ja auch GB-weise Metadaten, sonst würd sie ja schon laufen. Ausserdem bin ich ziemlich sicher das die DB mit ihrer Binären Suche viel häufiger auf die Platte zugreift.
a) Eine DB benutzt _nie_ binäre Bäume, das wäre idiotisch, sie benutzt balancierte Bäume.
Klar B-Bäume, gängiger versprecher in diesem Thread (sollte weniger Fernsehen beim Posten ;-)
Die Frage bleibt, braucht die DB mehr Plattenzugriffen als mein Ansatz?
b) Könnte ich genauso gut einen Hash-Index benutzen:
http://www.postgresql.org/docs/7.4/interactive/indexes-types.html
hmm soweit ich sehe nur einfache Defaulthashes, wo die Hashfkt nicht weiter optimiert werden kann.
Tschau
tolg
Hi,
Du verfügst über eine Statistik der Forumssuche in derart hoher Auflösung? Kommen da andere auch ran?
hehehe ich extrapoliere da mein verhalten, kann natürlich auch sein das 90% der Leute auf anhieb perfekte Queries reinhauen und sofort zufrieden sind... (ich glaubs nicht)
Oder die geben auf, wenn sie nicht sofort 'was finden und posten daraufhin im Forum.
Nein, ohne Daten ist es recht müßig über das Verhalten der Benutzer zu mutmaßen.
BTW: Du benötigst für den ganzen Schisselamäng nur eine einzige ordentliche Hashfunktion, nicht mehr. Auch wenn die Hashtabellen optisch als zusammengehörig erscheinen, so sind sie doch völlig unabhängig und Du kannst einen einmal mühselig errechneten Hashwert vollständig wiederverwenden.
??? na eben nicht! Seien h=k die zugehörigen Fkten, für gleichmächtige Hashes H,K. Die k(W) berechne ich ja jeweils nur für die Wi der Kollisionen in H, d.h. h(W1)=h(W2). Ich hätte dann in K einen GAU von Kollision, wo alle k(Wi) alle auf den gleichen Wert abgebildet werden. Die Fkten müssen sehr wohl unabhängig sein, und zwar bewiesenermaßen (!) um performant zu sein.
Tja, das hatte ich befürchtet, das ist auch sehr schlecht vorstellbar. Also nochmal:
Stell Dir vor, Du hast eine Hashtabelle H mit 5 Löchern {a,b,c,d,e} und eine Funktion f(x), die alle Elemente einer Menge S gleichmäßig auf diese Löcher abbildet. Ist |S| größer als |H| dann kommt es zu Mehrfachbelegung, zu Kollisionen. Nun steht hinter jenen Löchern von H je eine weitere Hashtabelle H_i = {f,g,h,i,j}.
Zuerst wird jedes Loch in H gefüllt (wir setzen einmal eine optimale Verteilung der Hashwerte voraus), nach fünf Vorgängen erfolgt also die erste Kollision, sagen wir mal in a. Wir brauchen nun also eine Hashfunktion, die ein Element aus S in H_i packt. Was hindert uns nun daran, ebenfalls f(x) zu nehmen? Dadurch, das H voll ist, wird eine _neue_ Hastabelle genommen, wir fangen sozusagen bei 0 an. D.h.: wir können den alten Hashwert nehmen, der funktioniert für H_i genauso gut oder schlecht, wie für H. Vorausgesetzt natürlich, das |H| = |H_i|, aber das trifft in Deinem Beispiel ja zu.
Jetzt verstanden? Na, ich sehe noch zweifelnde Blicke ...
Bastel Dir einfach ein Beispiel, oder mal's Dir auf, das hilft mir auch mitunter.
kann sein, aber die DB braucht ja auch GB-weise Metadaten, sonst würd sie ja schon laufen. Ausserdem bin ich ziemlich sicher das die DB mit ihrer Binären Suche viel häufiger auf die Platte zugreift.
So funktioniert eine DB nicht, das ist da schon etwas geschickter geregelt. Wenn ich mein "endlich mal meine Boomarks aufräumen" nicht schon seit Ewigkeiten vor mir her schieben würde, könnte ich Dir jetzt auch ein paar gute Links anbieten, aber auf die Schnelle finde ich hier nix. Vielleicht hast ja Du Glück und einer der zwei-drei Mitleser hat welche parat?
Obige Hashtabelle wäre sehr günstig, wenn alle Anfragen Einwortanfragen wären.
Einwortanfragen? Du meinst wenn der Query nur aus einem Wort besteht?
Ein Begriff, ja. Muß natürlich nicht nur ein Wort sein.
Bei Mehrwortanfragen wäre jedes Wort einzeln zu prüfen. Gut, das ist seltenst viel, das würde sich wahrscheinlich auch noch lohnen. Phrasensuche wäre aber schon schwieriger.
Wieso seltenst? Die Schnittmenge der Postinglisten muss halt gebildet werden. (gleich kommt sowas wie geordnete Listen dafür nicht optimal sind ... geschenkt ;-)
Schnittmenge bilden ist _sehr_ teuer. Noch teurer fast, als ein grep durch's Archiv. Wenn das sein muß, ist die ganze vorherige Optimierung für die Katz.
(Da es sortierte Listen bekannter Länge sind, könnte man die Schnittmengenbildung evt(!) auf nlogn runterbringen, aber auch nur als Best Case. Durchschnitt wäre n^2 und Worst case n^3. Mmh... nein, Worst Case käme gar nicht vor, oder?)
Ein Bloomfilter zwischen Eingabe und Cache macht da deutlich mehr Sinn.
Hab gerade mal bloomfilter http://en.wikipedia.org/wiki/Bloom_filterüberflogen. Durchaus faszinierend, aber wozu willst du den hier einsetzen? Teilstringsuche???
Nein, sondern genau dafür, wofür das Dingen ursprünglich gedacht war: um auf einfache Weise nachschauen zu können, ob mit einer recht genau bestimmbaren Wahrscheinlichkeit etwas gecached wurde. Das ließe sich per Javascript realisieren und so würde jeder mit eingeschaltetem Javascript die Server-Belastung reduzieren können.
(im Vertrauen, das alles hab ich nie studiert,
Ich auch nicht, ist also kein Grund.
Theorie der Hashes kenn ich aus nem CT-Artikel vor 5 Jahren,
Gut, _das_ ist ein Grund.
- (Posting) Für jedes neue Posting müssen pro enthaltenem Wort die Liste L(W) um die Refernez auf das neue Posting erweitert werden.
Wie ist dies Liste implementiert?
Erstmal trivial aufsteigend linear sortiert.
Warum nicht gleich als fertige Seite?
Brächte Vorteile wenn man nur die Differenzen abspeichern muß, desto mehr Listen passen ins RAM.
Das ist Microoptimierung, vergiss es schnell wieder.
(Du verbrauchst fast schon mehr Zeit diese Differenzen zu erstellen, als sie nachher gewinnen)
Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden.
... und schon ist das RAM voll.
Also ich halt jede Wette das der Zuwachs an Vokabeln des Forums über die Jahre abgeflacht ist.
Ich setz' 'n Kasten Bier dagegen.
Wie wäre es mit einem kurzem Proof-of-Concept?
Nur der Algo schnell in JS realisiert wie oben beschrieben?
Zum Beipiel.
Hmm das könnte ich sogar gut recyclen...
Altruismus hatt ich auch nicht vorausgesetzt.
Gut, ich bräuchte 2 Sätze Hashfkten zu einer vorgegebenen Bitlänge i, h_i, und k_ij wobei zu jeder bitlänge i,j die h_i und k_ij paarweise unabhängig sind.
(Für den PoC reicht auch ein Paar h, k unabhängig und Vokabular kleiner 2^(i+j))Wenns die gibt, dann klappts auch. (ich könnt jetzt suchen, aber du schüttelst das doch aus dem Ärmel, oder :)
CRC ist eine gute Möglichkeit, wenn Du die passenden primitiven Polynome n-ter Ordnung (n ist hier die Anzahl an Bits, also bei einem 16-Bit Hashwert brauchst Du ein gutverteiltes primitives Polynom 16ter Ordnung) wählst. Die sollten möglichst gut verteilt sein, dann kannst Du so einen CRC auch zum Hashen beutzen, auch wenn der dafür gar nicht vorgesehen ist. Leider hat sch noch kein Mathematiker die Mühe gemacht, ds soweit zu unetrsuchen, das dabei eine Funktion rauskommt, die so ein Polynom auf Anhieb finden kann, es gilt also leider T&E.
Das solltest Du dem Dateisystem überlassen, die modernen wie z.B. ReiserFS sind da kaum zu überbieten. Du kannst einafch schreiben, den
Rest übernimmt das FS.Wenn ich damit performant auf Zellen der K-Hashes zugreifen kann, gerne.
Wie denn sonst?
ich denke die DB arbeitet da schon ziemlich effizient.
Eben.
ja aber bei euren Worstcase-Szenarien geht die DB viel schneller in die Knie.
Das wollen wir nicht hoffen, das dabei die DB in die Knie geht, aber es sind in bestimmten Fällen eben aufwendigerer Anfragen zu bearbeiten.
Die hier skizierte Methode kannst du auf Servern mit jedem RAM/HD-Szenario realisieren, der auch Michaels Vollindex schlucken kann.
Die Bäume einer DB sind doch auf viel generellere Anforderungen hin optimiert, die hier gar nie auftreten werden. Z.B. müssen hier nicht täglich Millionen Postings eingetragen werden
Skalierbarkeit hat hier wenig mit zu tun.
oder Rollbacks gefahren werden und und und ...
Wenn Du eine Funktion der DB nie brauchst, dann kannst Du sie auch einfach ausbauen. Aber das sind alles Kleinigkeiten, die ich auch wieder zur Mikrooptimierung zählen würde. Mit einer geschickten Datenstruktur erreichst Du da schon deutlich mehr. Selbst beim Caching würde ich vorher sorgfältig die Gewohnheiten der Sucher studieren, bevor ich mich vor meinen Lieblingseditor setzte.
so short
Christoph Zurnieden
你好 Christoph,
Also nochmal:
Stell Dir vor, Du hast eine Hashtabelle H mit 5 Löchern {a,b,c,d,e} und
eine Funktion f(x), die alle Elemente einer Menge S gleichmäßig auf
diese Löcher abbildet. Ist |S| größer als |H| dann kommt es zu
Mehrfachbelegung, zu Kollisionen. Nun steht hinter jenen Löchern von
H je eine weitere Hashtabelle H_i = {f,g,h,i,j}.
Zuerst wird jedes Loch in H gefüllt (wir setzen einmal eine
optimale Verteilung der Hashwerte voraus), nach fünf Vorgängen
erfolgt also die erste Kollision, sagen wir mal in a. Wir brauchen
nun also eine Hashfunktion, die ein Element aus S in H_i packt.
Was hindert uns nun daran, ebenfalls f(x) zu nehmen?
Die Tatsache, dass wieder dieselben Kollisionen auftreten. Vergiss nicht:
du hast eine gleich grosse Hashtabelle H_i, das heisst, der Schluessel
kann in seiner Genauigkeit nicht vergroessert werden, sondern muss gleich
gross bleiben. In dem Fall haetten wir dieselbe Kollision noch mal, weil
wir zwei Eingangswerte haben, die bereits kollidiert sind. Beispiel,
nehmen wir an, wir haetten eine beliebige Tabelle, oben die Position und
damit den Hash-Wert und unten den Schluessel:
1|2|3|4|5
----------
a|b|c|d|e
Packen wir jetzt den Schluessel f dazu, bekommen wir eine Kollision:
1 |2|3|4|5
----------
af|b|c|d|e
Deshalb muss eine neue Hash-Tabelle aufgemacht werden, ich deute das mal
an:
1|2|3|4|5
----------
||b|c|d|e
|
------> 1|2|3|4|5
---------
| | | |
In diese neue Tabelle muessen jetzt a und f eingesetzt werden, jedoch mit
einem Schluessel in der gleichen Genauigkeit wie in der Stufe zuvor. Werfen
wir jetzt a in die Funktion, bekommen wir den Hash-Wert 1 heraus. Werfen
wir jetzt noch f in die Funktion, bekommen wir -- na? Ahnst du es? Genau,
wir bekommen auch 1 heraus, weil die Genauigkeit gleichgeblieben ist und
die Funktion nicht ausgetauscht wurde. Es muss ja zwangslaeufig so sein,
denn Hashing waere sinnlos, wenn die gleiche Funktion bei gleicher
Genauigkeit und gleichen Eingangswerten unterschiedliche Hash-Werte
auswerfen wuerde.
Bei Mehrwortanfragen wäre jedes Wort einzeln zu prüfen. Gut, das
ist seltenst viel, das würde sich wahrscheinlich auch noch lohnen.
Phrasensuche wäre aber schon schwieriger.Wieso seltenst? Die Schnittmenge der Postinglisten muss halt gebildet
werden. (gleich kommt sowas wie geordnete Listen dafür nicht optimal
sind ... geschenkt ;-)Schnittmenge bilden ist _sehr_ teuer. Noch teurer fast, als ein grep
durch's Archiv. Wenn das sein muß, ist die ganze vorherige Optimierung
für die Katz.
Naja, das halte ich fuer uebertrieben, ein Grep durchs Archiv duerfte
noch teurer sein, vor allem wenn man geschickt merged: die Begriffe sind
ja UND-verknuepft, also sucht man sich zuerst den Begriff mit den
wenigsten Treffern heraus und geht von da aus weiter. Aber du hast schon
recht, das kann die Datenbank vermutlich besser und schneller.
Also ich halt jede Wette das der Zuwachs an Vokabeln des Forums über
die Jahre abgeflacht ist.Ich setz' 'n Kasten Bier dagegen.
Und ich klaer auf ;-) Aber ich kriege was ab!
Maaan, dauert das... kein Wunder, bei der Menge an Daten und dem
“Zimmermannsalgorithmus”... *wart* Ok, also Ergebnisse:
new in 1998: 9228
new in 1999: 51678
new in 2000: 89827
new in 2001: 58391
new in 2002: 227148
new in 2003: 259379
new in 2004: 251905
Ich glaube, das duerfte alle Fragen beantworten *g* Christoph, ich krieg
die Haelfte ab *fg*
再见,
CK
你好 Christoph,
[...]
Maaan, dauert das... kein Wunder, bei der Menge an Daten und dem
“Zimmermannsalgorithmus”... *wart* Ok, also Ergebnisse:new in 1998: 9228
new in 1999: 51678
new in 2000: 89827
new in 2001: 58391
new in 2002: 227148
new in 2003: 259379
new in 2004: 251905Ich glaube, das duerfte alle Fragen beantworten *g* Christoph, ich krieg
die Haelfte ab *fg*
Hab vergessen, die Sourcen des Scripts:
http://forum.de.selfhtml.org/words.txt
再见,
CK
Hi
soweit ich überblicke bist du über das jede HTML-Seite gegangen statt gleich den Vollindex zu nehmen, warum?
Kann es sein dass du pro thread noch nen stampstring mitgezählt hast, das korreliert doch alles sehr stark mit den Archivgrößen...
Bye
Rolf
你好 LanX!,
soweit ich überblicke bist du über das jede HTML-Seite gegangen [...]
Nein, ich habe die _XML_-Dateien geparsed.
[...] statt gleich den Vollindex zu nehmen, warum?
Weil es viel schwerer zu kontrollieren gewesen waere.
Kann es sein dass du pro thread noch nen stampstring mitgezählt hast, das
korreliert doch alles sehr stark mit den Archivgrößen...
Nein, habe ich nicht. Saemtliche Attribute sind voellig unbetrachtet
geblieben.
再见,
CK
Hi
Ich vermute dieser Zuwachs hängt im Wesentlichen mit Typos zusammen.
Beispiel:
Suche nach "Arhciv" liefert 5 Treffer. http://suche.de.selfhtml.org/cgi-bin/such.pl?suchausdruck=Arhciv&wort=on&feld=alle&index_1=on&index_2=on&index_3=on&index_4=on&index_5=on&index_6=on&index_7=on&index_8=on&index_9=on&index_10=on&index_11=on&hits=100
nach "Arciv" liefert 8 Treffer
http://suche.de.selfhtml.org/cgi-bin/such.pl?suchausdruck=Arciv&wort=on&feld=alle&index_1=on&index_2=on&index_3=on&index_4=on&index_5=on&index_6=on&index_7=on&index_8=on&index_9=on&index_10=on&index_11=on&hits=alle
"Archiv" liefert aber weit über 9999 (maximum Hits)
Ein Kriterium zur Typoerkennung wäre also das relative Verhältnis der Wörter.
Wäre interessant zu überprüfen ob der Anteil der Typos an neuen Wörtern im Laufe der Zeit zunimmt, ich denke ja.
Kannst du mir mit dem deinem Skript eine Liste der neuen Wörter der Threads eines Tages in 1999 und in 2004 generieren?
Tschau
Rolf
Hi,
das korreliert doch alles sehr stark mit den Archivgrößen...
Ja, das haben schon andere festgestellt, das Du noch so große Corpuse sammeln kannst, die Menge an unterschiedlichen Worten wird proportional größer. Leider bis jetzt nur empirisch gefunden, formal begründen konnte das noch keiner.
so short
Christoph Zurnieden
Hallo ihr beiden,
Also ich halt jede Wette das der Zuwachs an Vokabeln des Forums über
die Jahre abgeflacht ist.Ich setz' 'n Kasten Bier dagegen.
Und ich klaer auf ;-) Aber ich kriege was ab!
Maaan, dauert das... kein Wunder, bei der Menge an Daten und dem
“Zimmermannsalgorithmus”... *wart* Ok, also Ergebnisse:new in 1998: 9228
new in 1999: 51678
new in 2000: 89827
new in 2001: 58391
new in 2002: 227148
new in 2003: 259379
new in 2004: 251905Ich glaube, das duerfte alle Fragen beantworten *g* Christoph, ich krieg
die Haelfte ab *fg*
na meinetwegen kann er dir den ganzen Kasten geben, mir fehlt das nötige Alk-Enzym.
Falls Zweifel auftreten, der Dialog war
----8<------------
Diese Reorganisation dürfte aber sehr selten vorkommen, weil das Vokabular des Forums nicht so schnell wächst.
»»
Davon kannst Du nicht ausgehen, eher davon ds es zwischenzeitlich heftige Sprünge geben wird. Es muß nur eine andere Programmiersprache modern werden, ja, nur ein kurzes Listing in einer anderen Sprache würde einen guten Hub ergeben.
Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden."
----8<------------
Also ich halt jede Wette das der Zuwachs an Vokabeln des Forums über die Jahre abgeflacht ist.
und bis 2004 hat sich der Zuwachs nicht nur abgeflacht sondern ist sogar zurückgegangen! Von diesem rückgängigen Zuwachs ausgehend müßten die Intervalle für eine Reorganisation mindestens quadratisch wachsen.
Q.E.D. :)
Prost
Rolf
你好 LanX²,
und bis 2004 hat sich der Zuwachs nicht nur abgeflacht sondern ist
sogar zurückgegangen!
2004 ist noch nicht vollstaendig archiviert worden.
再见,
CK
hi ck,
2004 ist noch nicht vollstaendig archiviert worden.
Shit! Wenn erstmal meine Postings hier hinzukommen, steigt die Wortentropie noch mal gewaltig... ;)
bye
rolf
Hi,
was treibt ihr euch denn noch im Forum rum? Bei mir war's die Prostata, die mich aus dem Bett gejagt hat, was ist eure Entschuldigung?
Was hindert uns nun daran, ebenfalls f(x) zu nehmen?
Die Tatsache, dass wieder dieselben Kollisionen auftreten.
Ja. Und?
In der zweiten Hastabelle ist das Loch aber noch leer: trotz gleichem Hash keine Kollision! Da guckense, was?
Erst jeder weitere gleicher Hashwert führt zur Kollision. Würde hier eine unterschiedliche Hashfunktion helfen? Diese unterschiedliche Hashfunktion würde höchstwahrscheinlich ein anderes Loch nehmen und die Kollisionen würden auf andere Einganswerte erfolgen. Da aber auch Eingangswerte Kolisionen ergeben können, die mit der ersten Hasfunktion aufgelöst werden konnten gleicht sich das statistisch wieder aus (Ist dann zwar in einem anderem "Subhash" aber da kann die Statistik nix für).
Es hätte also einige minimale Vorteile zwei Hashfunktionen zu nehmen, jedoch würde es theoretisch auch mit einer einzigen gehen. Und wir diskutieren hier ja schließlich über die Theorie, oder?
Schnittmenge bilden ist _sehr_ teuer. Noch teurer fast, als ein grep
durch's Archiv. Wenn das sein muß, ist die ganze vorherige Optimierung
für die Katz.Naja, das halte ich fuer uebertrieben, ein Grep durchs Archiv duerfte
noch teurer sein,
Hey, ein _klein_ wenig rethorische Polemik darf auch mir verstattet sein, oder?
Ich wollte auch nur dsarauf hinweisen, das die Komplexität (im informationstechnischem Sinne) von "nur mal eben die Schnittmenge bilden" sehr hoch ist, in der Theorie sogar O(n^3) beträgt (aber meist optimiert werden kann, über O(n^2) dürfte es seltenst kommen)
[Statistik]
Ich glaube, das duerfte alle Fragen beantworten *g* Christoph, ich krieg
die Haelfte ab *fg*
Ohne Algorithmus kein Bier.
Den Kasten habe ich aber schon besorgt.
Oh, hat er doch noch offengelegt, sorry, nehme alles zurück und behaupte das Gegenteil (sage aber nicht wovon). Na, mal schauen ... ah, Moment was? 2004 _nicht_ vollständig archiviert? Fällt also raus? Dann also wie üblich: höchster und niedrigster Wert raus, damit habe ich Recht und saufe den Kasten alleine. Prost.
Oder ich schlepp Dich mit zu madmaxens Ausstellung und wir plündern einfach dessen Buffet. Käme mir zwar nicht billiger bei den Sprit- und Bierpreisen, wäre aber logistisch einfacher.
so short
Christoph Zurnieden
你好 Christoph,
Was hindert uns nun daran, ebenfalls f(x) zu nehmen?
Die Tatsache, dass wieder dieselben Kollisionen auftreten.
Ja. Und?
In der zweiten Hastabelle ist das Loch aber noch leer: [...]
Nein, du musst ja den die Kollision verursachenden Schluessel mit in
diese neue Hash-Tabelle legen. Du hast den Wert, der bereits in der
Ursprungstabelle war und den neuen Wert, die musst du beide in die
neue Hash-Tabelle legen.
Oder ich schlepp Dich mit zu madmaxens Ausstellung und wir plündern
einfach dessen Buffet. Käme mir zwar nicht billiger bei den Sprit- und
Bierpreisen, wäre aber logistisch einfacher.
Hehe, wenn du ueber Dortmund faehrst? ;-)
再见,
CK
Hi,
In der zweiten Hastabelle ist das Loch aber noch leer: [...]
Nein, du musst ja den die Kollision verursachenden Schluessel mit in
diese neue Hash-Tabelle legen. Du hast den Wert, der bereits in der
Ursprungstabelle war und den neuen Wert, die musst du beide in die
neue Hash-Tabelle legen.
Oh weh, ich sollte das aufmalen, nur wie?
Ho_1->Hn_a
Ho_2->Hn_b
Ho_3->Hn_c
Ho_i sollen die Löcher in der ersten Hashtabelle sein, Hn_i die sekundären Hastabellen.
Hn_i1->LLn_a
Hn_i2->LLn_b
Hn_i3->LLn_c
Hn_ij sollen die Löcher in der sekundären Hashtabelle sein, LLn_i die abschließenden Linked-Lists.
Eine Kollision durch die Funktion h(x)=y wird verarbeitet, indem statt der sonst üblichen LLs eine weiter Hashtabelle drangehangen wird. Bei der ersten Kollision ist die aber noch komplett leer. Egal welche Hashfunktion Du nimmst (vorausgesetzt sie trifft am Ende irgendeines der Löcher) Du triffst auf ein leeres Loch -> keine Kollision. Beim zweitem Mal triffst Du auf ein volles Loch -> Kollision -> LinkedList.
Wenn Du nun eine andere Hashfunktion h(x)=z nimmst, dann hast Du insgesammt weniger Kollisionen, das ist korrekt. Aber diese andere Hashfunktion ist nicht _zwingend_ nötig für die Funktion.
Sie ist aber eine "ordentliche" Optimierung, da sie mit wenig Aufwand (es ist ja wirklich nur _eine_ weitere Hashfunktion nötig, wenn auch eine genauso gute, wie die Erste) guten Effekt erzielt.
Anders sieht das natürlich aus, wenn meine ursprüngliceh Vermutung gestimmt hätte, das statt der abschließenden LinkedLists stets eine weitere Hashtabelle benutzt worden wäre. Dann wäre nicht nur für jede Hashtabelle eine gesonderte Hashfunktion nötig, sondern es hätte überhaupt nicht funktioniert, da hier eine unendliche große (gut: abzählbar unendlich große, hilft hier aber auch nix) Eingangsmenge angenommen wurde.
Oder ich schlepp Dich mit zu madmaxens Ausstellung und wir plündern
einfach dessen Buffet. Käme mir zwar nicht billiger bei den Sprit- und
Bierpreisen, wäre aber logistisch einfacher.Hehe, wenn du ueber Dortmund faehrst? ;-)
Sind gerade mal - zu faul zum nachschauen, aber gut geschätzt - etwa 30 km Umweg. Der Kasten Oettinger ist hier gerade im Angebot für 4,29 EUR. Da tut sich also nicht viel.
so short
Christoph Zurnieden
你好 Christoph,
Oh weh, ich sollte das aufmalen, nur wie?
Ja, ich wohl auch....
Eine Kollision durch die Funktion h(x)=y wird verarbeitet, indem statt
der sonst üblichen LLs eine weiter Hashtabelle drangehangen wird.
Soweit richtig.
Bei der ersten Kollision ist die aber noch komplett leer.
Bei der ersten Kollision muessen zwei Werte in eine bis dahin leere
Hash-Tabelle gelegt werden, um es mal zu praezisieren.
Egal welche Hashfunktion Du nimmst (vorausgesetzt sie trifft am Ende
irgendeines der Löcher) Du triffst auf ein leeres Loch -> keine
Kollision. Beim zweitem Mal triffst Du auf ein volles
Loch -> Kollision -> LinkedList.
Da du aber zwei Werte in eine leere Tabelle legen musst (s.o.) hast du
diese Kollision in der zweiten Ebene direkt bei der ersten Kollision in
der ersten Ebene.
Wenn Du nun eine andere Hashfunktion h(x)=z nimmst, dann hast Du
insgesammt weniger Kollisionen, das ist korrekt. Aber diese andere
Hashfunktion ist nicht _zwingend_ nötig für die Funktion.
Verwendet man keine zweite Hash-Funktion ist die Verwendung einer
Hash-Tabelle in der zweiten Ebene total sinnbefreit. Man verschwendet
damit Speicher und gewinnt keinerlei Performance, im Gegenteil.
再见,
CK
Hi,
Eine Kollision durch die Funktion h(x)=y wird verarbeitet, indem statt
der sonst üblichen LLs eine weiter Hashtabelle drangehangen wird.Soweit richtig.
Bei der ersten Kollision ist die aber noch komplett leer.
Bei der ersten Kollision muessen zwei Werte in eine bis dahin leere
Hash-Tabelle gelegt werden, um es mal zu praezisieren.
Ah, jetzt verstehe ich: Du möchtest nicht nur das Problemkind, sondern alles in die zweite Tabelle packen?
Warum?
Ist das Loch der ersten Tabelle gefüllt (= Kollision) heißt das doch schon, das etwas dagegen getan werden muß, die an diesem Loch liegende zweite Hashtabelle genutzt werden soll (in Pseudocode):
if(Loch_n == besetzt){
use_other(hashtabelle[Loch_n], hash_value, value);
}
Eine zweite Hashfunktion ist wirklich nicht essentiell, alle nötigen Informationen sind bereits vorhanden.
Ob das Sinn macht ist dann allerdings eine andere Frage, das ist wohl wahr. (es würde rein theoretisch eine Vergrößerung der primären Hashtabelle vermeiden helfen, eine Art diskrete und auch finite Dynamik sozusagen. Wäre vielleicht mal eine Untersuchung mit PoC wert?)
so short
Christoph Zurnieden
你好 Christoph,
Ah, jetzt verstehe ich: Du möchtest nicht nur das Problemkind, sondern
alles in die zweite Tabelle packen?
Richtig.
Warum?
Weil es speichereffizienter ist. Sonst muesste man in einem Loch Platz fuer
zwei Werte haben, das bedeutet 2x soviel Speicher-Aufwand.
Du hast natuerlich recht, wenn du sagst, es ist auch anders _moeglich_. Aber
inwieweit das Sinn macht ist eine andere Frage.
再见,
CK
Hi,
es speichereffizienter ist.
nichts ist umsonst außer dem Tod und selbst der kost' das Leben.
Sonst muesste man in einem Loch Platz fuer
zwei Werte haben, das bedeutet 2x soviel Speicher-Aufwand.
Der zweite Wert ist ein popeliger Pointer auf die Subhashtabelle. Wäre auch sonst ein Pointer auf die LinkedList. Du brauchst also noch nicht einmal mehr Speicher dafür.
Die Information, die Du meinst zu brauchen ist boolscher Natur, der Umstand, das das Loch belegt ist, das eine Kollisison überhaupt stattfindet, ist schon ausreichend als Grund auf die zweite Hastabelle zu wechseln.
Aber inwieweit das Sinn macht ist eine andere Frage.
Es wäre möglich eine Hastabelle, wenn auch nur in engen Grenzen, dynamisch zu erweitern. Ohne ein Rebuild. Komlexität wäre dabei rein theoretisch O(1+m) wobei m die Tiefe der "Subhashtabellenstaffelung" wäre. Grenze des sinnvollen Ausbaus wäre damit sogar genau berechenbar.
Probleme sind auch absehbar: vorher zu bestimmende Größe der Ausbaustufe, es macht keinen Sinn nur um je 1*n Teilstücke zu vergrößern, die angefügten Unterhashtabellen sollten idealerweise immer genau so groß wie die voherige Hashtabelle sein. Speicher kann erst zur Runtime angefordert werden, aber das ist ja nicht unbedingt etwas schlechtes und es käme auch nur selten vor. Eigentliches Problem hierbei ist, das auch der neue Standard maximal Chunks von 64 kib _garantiert_. Das erforderte evt eine komplizierte eigene Speicherverwaltung. Trifft aber auch nur auf die theoretischen Überlegungen zu und hat natürlich auch nix mit dem Algorithmus selber zu tun.
Letztes Problem ist natürlich eindeutig: _riesiger_ Speicherverbrauch. Wenn bei einer Hashtabelle mit 2^16 Löchern jedes Loch einmal kollidiert und nach obigem Vorschlag die Subhashtabellen genauso groß, wie das vorherige Hash, bleiben am Ende 2^32 Löcher und Speicherbedarf dafür.
Alles also mehr eine akademische Übung, wenn auch eine interessante und jetzt muß ich wirklich in die Heia.
so short
Christoph Zurnieden
你好 Christoph,
Sonst muesste man in einem Loch Platz fuer
zwei Werte haben, das bedeutet 2x soviel Speicher-Aufwand.Der zweite Wert ist ein popeliger Pointer auf die Subhashtabelle.
Das ist ja voellig Wuppe. Wenn ich statt 4 Byte pro Zelle 8 Byte brauche
(einen Pointer auf das Element, einen Pointer auf den Hash zweiter Ebene),
dann ueberlege ich mir das.
Wäre auch sonst ein Pointer auf die LinkedList.
Nein.
Die Information, die Du meinst zu brauchen ist boolscher Natur, der
Umstand, das das Loch belegt ist, das eine Kollisison überhaupt
stattfindet, ist schon ausreichend als Grund auf die zweite Hastabelle
zu wechseln.
Aeh, ja, das hat ja keiner bestritten. Aber ich brauche in jedem Loch 8
Byte statt 4 (wenn man von 4-Byte-Pointern ausgeht), wenn ich in einer
Zelle zwei Werte speichern muss (naemlich den neuen Hash zweiter Ordnung
und den alten Wert). Das macht bei einer Tabelle mit 2^16 = 65536
Elementen dann 256KB mehr. Packe ich jedoch auch das alte Element in die
Tabelle zweiter Ordnung, mit einer _anderen_ Hashfunktion oder einer
genaueren Hash-Funktion, dann kann ich mir das sparen.
再见,
CK
Hi,
gepostet frühmorgens um halb Acht? Immer noch auf? "Schon wieder" wäre für Dich als Student ja doch eher unwahrscheinlich, oder?
Wäre auch sonst ein Pointer auf die LinkedList.
Nein.
Tja, und blöderweise hast Du da Recht. Normalerweise ist in dem Fall ja _statt_ des Wertes der Pointer zur LL im Loch nicht _zusätzlich_ wie das hier der Fall sein müßte.
Da es aber schon mit insgeamt(!) 2 anständigen Hashfunktionen klappt, werde ich mich am Wochenende mal an ein Proof of Concept machen.
Nein, natürlich nicht speziell für die Forumssuche (warum auch) sondern ganz allgemein.
Aeh, ja, das hat ja keiner bestritten.
Dann bitte ich um Entschuldigung: Mißverständnis.
Packe ich jedoch auch das alte Element in die
Tabelle zweiter Ordnung, mit einer _anderen_ Hashfunktion oder einer
genaueren Hash-Funktion, dann kann ich mir das sparen.
Ob eine genauere Hashfunktion hier nützt wage ich zu bezweifeln, da sie keine Bedingung hat, andere Kollisionen zu bieten, sie ist ja "nur" genauer. Muß schon perfekt sein, um funktionieren zu können. Es müßte also eine (theoretisch echt zufällig gewählte) andere Hashfunktion sein, bei Nutzung von CRC z.B. ein anderes primitives Polynom (da die aber unangenehmerweise nicht alle gleich sind wäre "echt zufällig gewählt" ohne Vorauswahl nicht sehr günstig womit dann "echt zufällig" natürlich nicht mehr gilt).
so short
Christoph Zurnieden
PS:
Der Rolf (aka LanX) hat mri gerade eine Mail geschrieben, weil heute Nacht ca 4:30 das Forum eine merkwürdiege Fehlemeldung von sich gab, die ich lettzte Tage auch schon mal hatte:
"Leider konnte keine Verbindung zum Server hergestellt werden. (Grund: %s) "
Es kann ja viel passieren, aber: "(Grund: %s)"?
CZ
你好 Christoph,
gepostet frühmorgens um halb Acht? Immer noch auf? "Schon wieder" wäre
für Dich als Student ja doch eher unwahrscheinlich, oder?
Doch, ich bin heute mal frueh aufgestanden, um 07:00 -- um mich wieder an
die Zeiten waehrend der Vorlesungen zu gewoehnen :)
Wäre auch sonst ein Pointer auf die LinkedList.
Nein.
Tja, und blöderweise hast Du da Recht. Normalerweise ist in dem Fall ja
_statt_ des Wertes der Pointer zur LL im Loch nicht _zusätzlich_ wie das
hier der Fall sein müßte.
Ja, richtig.
Packe ich jedoch auch das alte Element in die
Tabelle zweiter Ordnung, mit einer _anderen_ Hashfunktion oder einer
genaueren Hash-Funktion, dann kann ich mir das sparen.Ob eine genauere Hashfunktion hier nützt wage ich zu bezweifeln, da
sie keine Bedingung hat, andere Kollisionen zu bieten, sie ist
ja "nur" genauer.
Was ich mit genauere Hash-Funktion meinte war, die Hash-Funktion des
Hashes aus der ersten Ebene benutzen, aber das Ergebnis nicht abschneiden
sondern in einer hoeheren Genauigkeit zu benutzen. Da muss man dann aber
auch mit groesseren Tabellen leben. Muss man halt abwaegen.
再见,
CK
Hi
Was ich mit genauere Hash-Funktion meinte war, die Hash-Funktion des
Hashes aus der ersten Ebene benutzen, aber das Ergebnis nicht abschneiden
sondern in einer hoeheren Genauigkeit zu benutzen. Da muss man dann aber
auch mit groesseren Tabellen leben. Muss man halt abwaegen.
OK, also subdirekte Zerlegung, dabei gilt
"An interesting option is to produce a hash value that is twice as big as what you need, then use the first half as the first hash and the second half as the second hash. See checksum.c, for example. This can guarantee that hash values collide slightly less often than if the functions were truly independent."
http://burtleburtle.net/bob/hash/hashfaq.html#twice
Ich würde die Fkt auf jeden Fall erst darauf abtesten.
Es gäb hier übrigens noch eine Option die K_i nachträglich zu optimieren in dem man in der entsprechenden H-Zelle eine Bitmaske hinterlegt statt nur die Anzahl der abzuschneidenden Bits.
Man könnte also durch Wahl der richtigen Projektion die Kollisionen minimieren, was aber andererseits mit Organisationsoverhead erkauft würde.
Mikrooptimierung? Je nachdem wie teuer der Plattenzugriff ist, ist er aber IMHO nicht.
Tschau
Rolf
再见,
CK
你好 LanX!,
Mikrooptimierung? Je nachdem wie teuer der Plattenzugriff ist, ist er
aber IMHO nicht.
Oho, das sind grosse Worte. Plattenzugriffe sind _verdammt_ teuer, nicht
umsonst wurden B-Baeume eingefuehrt.
再见,
CK
Hi CK
Mikrooptimierung? Je nachdem wie teuer der Plattenzugriff ist, ist er
aber IMHO nicht.
Oho, das sind grosse Worte. Plattenzugriffe sind _verdammt_ teuer, nicht
umsonst wurden B-Baeume eingefuehrt.
Warst du nicht derjenige der nicht ständig Hashes reorganisieren wollte?
Diese Reorga würde bedeuten den gesamten Hash auf der Platte umzuschreiben (!), ausserdem müßte ich erst festtellen dass überhaupt "zu viele" Kolisionen da sind, was ja auch kostet.
Bei den seltenen Verdopplungen der K-Hashes könnte ich das zwar sowieso miterledigen, ich zweifle ob der Zeitgewinn das in usnerem Usecase rechtfertigt. Schließlich ist es bei jedem Plattenzugriff die Hashfkt p zu maskieren auch teurer als einfach ein paar bist wegzushiften.
Tschau
rolf
你好 LanX!,
Mikrooptimierung? Je nachdem wie teuer der Plattenzugriff ist, ist er
aber IMHO nicht.
Oho, das sind grosse Worte. Plattenzugriffe sind _verdammt_ teuer, nicht
umsonst wurden B-Baeume eingefuehrt.Warst du nicht derjenige der nicht ständig Hashes reorganisieren wollte?
Sicherlich nicht, nein. Ich habe immer gesagt, dass das zu vermeiden
ist.
Diese Reorga würde bedeuten den gesamten Hash auf der Platte
umzuschreiben (!), [...]
Einer der Gruende, warum ich von einem Hash-Index ueber das Archiv
nicht ueberzeugt war.
[...] ausserdem müßte ich erst festtellen dass überhaupt "zu viele"
Kolisionen da sind, was ja auch kostet.
Na, bei einer gleichmaessigen Hash-Funktion ist der Aufwand fuer das
Feststellen O(1): man kriegt ja mit, wieviele Elemente der Hash hat.
再见,
CK
Hi CK,
Diese Reorga würde bedeuten den gesamten Hash auf der Platte
umzuschreiben (!), [...]Einer der Gruende, warum ich von einem Hash-Index ueber das Archiv
nicht ueberzeugt war.
ich meinte dir Reorga eines K_i hashes.
[...] ausserdem müßte ich erst festtellen dass überhaupt "zu viele"
Kolisionen da sind, was ja auch kostet.Na, bei einer gleichmaessigen Hash-Funktion ist der Aufwand fuer das
Feststellen O(1): man kriegt ja mit, wieviele Elemente der Hash hat.
wie meinste das ... du meinst die Zahl der Kollisionen ergibts sich als Schätzwert aus der Zahl der Einträge, die irgendwann mitprotokolliert wurden?
Wenn die Hashfkt mit der Grundmenge aus dem Forum wirklich so nah am theoretischen Optimum arbeitet, sollte es IMHO auch egal sein welche Bits ich maskiere. Solche Kollisisonsoptimierungen machen nur als Korrektivum Sinn, also wenn überhaupt erst in einer späteren Phase betrachten.
Man könnte übrigens auch schlichtweg die Gesamtzahl der Kollisionen
in einem K_i mitzählen, häufen sich die Plattenzugriffe deswegen, wärs ein Grund zu reorganisieren.
Eine andere Optimierung wäre es auch die Kollisionen die zu einer Zelle j vorhanden sind zu priorisieren, soll heißen in j steht der beliebteste, in der "Alternativzelle" der zweitbeliebteste, usw.
Aber bei einer guten Hashfkt sollte das auch keine Rolle spielen, weil zu selten sich mehrere Kollisonen auf einem j konzentrieren sollten, ohne dass sowieso das Hash verdoppelt wurde.
Tschau
rolf
你好 LanX²,
[...] ausserdem müßte ich erst festtellen dass überhaupt "zu viele"
Kolisionen da sind, was ja auch kostet.Na, bei einer gleichmaessigen Hash-Funktion ist der Aufwand fuer das
Feststellen O(1): man kriegt ja mit, wieviele Elemente der Hash hat.wie meinste das ... du meinst die Zahl der Kollisionen ergibts sich
als Schätzwert aus der Zahl der Einträge, die irgendwann mitprotokolliert
wurden?
Ja, genau.
再见,
CK
Hi,
Aber das funktioniert erst, wenn der Hashwert gut durchmischt ist, guter Pseudozufall erzeugt wurde. Ist ein ziemlicher Aufwand, den er da betreibt. Aber hat auch seine Anwendungen, klar.
so short
Christoph Zurnieden
PS:
Darf ich jetzt C&P Deiner Mail oder nicht?
CZ
Hi Christoph
sorry hab den überblick über neue Posts verloren ...
PS:
Darf ich jetzt C&P Deiner Mail oder nicht?
ja logisch, ich hab die mail doch mittlerweile auch gepostet https://forum.selfhtml.org/?t=97702&m=598741und CKs Antwortmail unlautererweise auch zitiert.
Tschau
rolf
你好 LanX²,
PS:
Darf ich jetzt C&P Deiner Mail oder nicht?ja logisch, ich hab die mail doch mittlerweile auch gepostet
https://forum.selfhtml.org/?t=97702&m=598741 und CKs
Antwortmail unlautererweise auch zitiert.
Wuerde mich das stoeren haette ich es schon lange geloescht >;)
再见,
CK
Hi,
sorry hab den überblick über neue Posts verloren ...
Das Forum hat auch eine RSS-Feed, so ist das nicht.
Aber gut, ich nutze den auch nicht, schaue lieber hin und wieder so mal rein.
PS:
Darf ich jetzt C&P Deiner Mail oder nicht?
ja[...]
Aber die Quotingzeichne ändere ich jetzt nicht, da bin ich viel zu faul zu. (Privaten Kram gestrichen und noch etwas gekürzt, aber nicht geändert. Alle Fehler die vorher drin waren, sind also drin geblieben)
Aber da auch ich mich irren kann und es auch häufig tue, klapper ich das mal durch.
»» Ja, genau das meinte ich und das bedeutet eine Komplexität von
O(n*log(n)).Nö, ich muss im Worstcase jedes _höchtens_insgesamt_genau_ 1 mal anfassen,
nicht jede Paarung.Sei p,q die Länge zweier _geordneter_ Listen, dann braucht obiger Algo
höchstens p+q Vergleiche, desdewegen O(n) mit n=p+q.Bitte genau lesen, ich _streiche_ die untersten Elemente in beide Listen,
beide sortiert und gehe linear weiter.
Das ist Best Case, denn ein Streichen _beider_ Elemente bedeutet, das der Vergleich erfolgreich war. Ist es das wirklich?
Worst Case:
S_1 = {a,b,c}
S_2 = {x,y,z}
Nötige Vergleiche:
ax
ay
az
bx
by
bz
cx
cy
cz
Dadurch, das die Listen geordnet sind und die Richtung bekannt, wären nötig:
ax
bx
cx
(bzw umgekehrt)
Dadurch, das auch noch die Länge bekannt ist _und_ das zugrundeliegende Alphabet:
ax
Da wir so viel wissen ist also aus dem ehemaligem WorstCase hier der BestCase geworden, wir können in O(1) feststellen, ob die Schnittmenge leer ist.
Schonmal nicht schlecht.
Wie sieht das denn mit zwei gleichen Mengen S_1 = S_2 aus?
S_1 = {a,b,c}
S_2 = {a,b,c}
Worst case:
aa
bb
cc
Geordnet:
aa
bb
cc
Länge und Alphabet bekannt:
aa
bb
cc
Das ist O(n).
Kann man irgendeinen Fall konstruieren, der komplizierter ist? Ich finde keinen, also ist WorstCase O(n).
Fehler gefunden?
O(log(n)) bräuchte ich nur zum zusätzlichen Ordnen, wenns nicht bereits
wäre.
Um etwas zu ordnen, mußt Du irgendwann schon feststellen, ob es geordnet ist, Mindestkomplexität ist also O(n), im Schnitt liegen die guten etwas besser als O(n*log(n)). Bei gleichn voraussetzungen, wie oben bei den Schnittmengen, gibt es aber auch noch Pidgeonsort, das ist O(1) und funktioniert ähnlich, wie eine Hashtabelle (der 2.6er Linuxkernel verwaltet so z.B. seine Pozesse)
Ich glaub auch nicht dass es besser ginge als O(n), da sich für jeden
"besseren" Ansatz (z.B mit Baumsortierung) ein Gegenbeispiel konstruieren
ließe, wo doch jedes Element angefasst werden muss.
Und die Ordnung richtet sich ja nach der _maximalen_ Zeitkomplexität.
Na, Best- und Worstcase werden schon meist angegeben, wenn sie sich
signifikant und begründbar unterscheiden. Ist eine wichtige
Entscheidungshilfe. BestCase hier oben ist ja schließlich O(1)! Wenn ich also
nur entscheiden will, ob die Schnittmenge leer ist und die Wahrscheinlichkeit
dafür auch relativ hoch, könnte sich der Aufwand der vorherigen Sortierung
durchaus lohnen.
Ah, BTW: das Suchen in geordneten Listen ist normalerweise O(log(n)) (per Divide&Conquer, das Übliche also), habe ich also oben irgendwo einen Fehler gemacht?
(Was nicht heißen soll, dass man im Schnitt nicht schnellere Ergebnisse
haben kann, z.B. Baumsortierung um ganze Teillisten auszuschließen, aber
das wäre jetzt für _mich_ Microoptimierung)
Ja, das wäre es durchaus, Vorsortierung ist hier wohl die einzig zulässige Optimierung.
»» Du mußt jeden einmal anfassen (n), weil Du aber nach dem Vergleich
streichen kannst (bzw eine Suche in einer sortierten Liste bekannter Länge
eh nur log(n) dauert), mußt Du nicht n-mal vergleichen, sondern nur
log(n)-mal.
Das hieß für mich immer O(n*log(n)), aber ich lasse mich gerne eines besseren belehren.
- streiche ich in beiden listen
- vergleiche ich immer nur die beiden untersten.
(rein formal müßte ich noch verlangen dass es in den Listen keine Duplikate
gibt, aber geschenkt oder?)
Das war schon vorausgesetzt. Ist auch egal, wenn die Liste geordnet ist.(Nur funktioniert dann das Spiel unten nicht, das setzt schon voraus, das es keine Doubletten gibt.)
Überzeugt? >:)
Wie das funktioniert? Das war mir schon klar, nur über die Notation bzgl der Komplexität herrschte doch Uneinigkeit?
so short
Christoph Zurnieden
Hi
ne expliziteres Posting ist leider mit meinem Rechner abgestürzt aber ich denke folgende Argumente reichen:
Sei p,q die Länge zweier _geordneter_ Listen, dann braucht obiger Algo
höchstens p+q Vergleiche, desdewegen O(n) mit n=p+q.Bitte genau lesen, ich _streiche_ die untersten Elemente in beide Listen,
beide sortiert und gehe linear weiter.Das ist Best Case, denn ein Streichen _beider_ Elemente bedeutet, das der Vergleich erfolgreich war. Ist es das wirklich?
OK ... räusper ... ich streiche mindestens eins der beiden Startelemente Listen und gehe linear weiter.
D.h. nach spätestesten p+q Schritten habe ich alle gestrichen und der Algo terminiert, das ist linear.
Denk an die frühen Assemblersprachen wo man vor jeder Operation erstmal die Werte in ein Register laden mußte,
hier müßte ich vor jedem Vergleich mindestens einen neuen Wert in einen von 2 Register laden, ist er erstmal drinnen brauche ich ihn nie wieder anzufassen.
O(log(n)) bräuchte ich nur zum zusätzlichen Ordnen, wenns nicht bereits
wäre.Um etwas zu ordnen, mußt Du irgendwann schon feststellen, ob es geordnet ist, Mindestkomplexität ist also O(n), im Schnitt liegen die guten etwas besser als O(n*log(n)). Bei gleichn voraussetzungen, wie oben bei den Schnittmengen, gibt es aber auch noch Pidgeonsort, das ist O(1) und funktioniert ähnlich, wie eine Hashtabelle (der 2.6er Linuxkernel verwaltet so z.B. seine Pozesse)
ja da habe ich was falsch abgeschrieben, Pidgeonsort schau ich mir gerne bald mal an :)
Obwohl ich in diesem Fall auch Bloomfilter spannend fände.
Na, Best- und Worstcase werden schon meist angegeben, wenn sie sich
signifikant und begründbar unterscheiden. Ist eine wichtige
Entscheidungshilfe. BestCase hier oben ist ja schließlich O(1)!
Bitte? Ne, dazu müßte eine Liste einelementig sein! Ein Bestcase ist wenn der letzte der einen Liste kleiner ist als der erste der anderen Liste (aufsteigend geordnet) und es deswegen keinen Schnitt gibt. Trotzdem mußt du erst zum Ende der einen Liste gelangen.
»» Du mußt jeden einmal anfassen (n), weil Du aber nach dem Vergleich
streichen kannst (bzw eine Suche in einer sortierten Liste bekannter Länge
eh nur log(n) dauert), mußt Du nicht n-mal vergleichen, sondern nur
log(n)-mal.Das hieß für mich immer O(n*log(n)), aber ich lasse mich gerne eines besseren belehren.
Die Frage ist wie du n wählst, beschränken wir uns auf p,q als Längen der Listen, log() der aufgerundete log_2(). Dann gilt tatsächlich grob
T_2(p,q) = p*log(q)
was aber nur für p << q besser ist als
T_1(p,q) = p+q.
A1 sei mein Vorschlag, A2 die logarithmische Suche.
T() beschreibt die Zeitkomplexität, die Anzahl aller Operationen eines Algo. Das Landausymbol O() beschreibt dann die asymptotische Entwicklung des schlechtesten T().
Ich hab das Wochenende noch ein bißchen gegrübelt und meine mit 2 Ansätzen auf
T_3(p,q)= p* log(q/p) + p
hinzukommen, indem ich A1 und A2 kombiniere.
1. Ansatz :
(OBdA p<q) wähle ich den Streichalgorithmus und vergleiche alle Elemente {x aus P} mit denen {y aus Q die Schrittweite q/p auseinanderliegen}. Dann kann ich jedem x aus P ein Intervall der Länge q/p in Q zuordnen., wo er liegen müßte. Diese Intervalle durchsuche ich anschließend binär.
T_3 hat den Vorteil das er immer (!) kleiner als T_1, T_2 ist. Also Methode der Wahl, ich glaube auch nicht an eine Verbesserungsmöglichkeit.
Der 2. Ansatz ginge mit Divide&Conquer: stetiges halbieren beider Intervalle und zurückführen auf je 2 Teilproblem mit T(p/2,q/2). Allerdings saukomplizierte Fallunterscheidungen - habe deswegen abgebrochen.
Wie das funktioniert? Das war mir schon klar, nur über die Notation bzgl der Komplexität herrschte doch Uneinigkeit?
Es geht um asymptotische Entwicklung!
O(n) beschreibt die Annäherung an eine Gerade bei großen Werten. Also egal ob wir n =p,q, oder p+q wählen existiert immer eine Konstante c sodass T(p,q)< c*n.
Tschau
rolf
Hi,
ne expliziteres Posting ist leider mit meinem Rechner abgestürzt
Ja, auch Windows hat seine Vorteile >;->
OK ... räusper ... ich streiche mindestens eins der beiden Startelemente Listen und gehe linear weiter.
D.h. nach spätestesten p+q Schritten habe ich alle gestrichen und der Algo terminiert, das ist linear.
Ja, das kommt davon, wenn man die Mails/Postings linear [sic] beantwortet. Das gilt dann aber für uns beide befürchte ich.
Denk an die frühen Assemblersprachen wo man vor jeder Operation erstmal die Werte in ein Register laden mußte,
Das gilt doch auch noch für die modernen Assemblersprachen?
Aua, aua, doch nich' gleich hauen!
(Ich hab zur Zeit und leider auch "mal wieder" eine Rechtschreibung drauf, das geht doch auf keine Kuhhaut und jetzt habe ich gerade auch noch den Absatz gelöscht auf den sich dieser Klammerinhalt bezog. Tsk tsk tsk.)
ja da habe ich was falsch abgeschrieben, Pidgeonsort schau ich mir gerne bald mal an :)
Ich putze mir gearde angelegentlich meine Sehhilfe, wenn Du zufällig gerade mit Telegraphenmasten winken solltest sehe ich das nicht.
Obwohl ich in diesem Fall auch Bloomfilter spannend fände.
Ist in Arbeit, aber da es nun auch in Javascript funktionieren muß, ist das leider nicht ganz so einfach, wie das bischen Bitschuppserei in C. Zudem wird der Bitstring, der den Bloomfilter darstellt verdammt lang. Bei 4 Hashfunktionen und den irgendwann einmal geschätzten 400 Einträgen bräuchte man für eine Fehlerrate von einem Promille 8172 Bits für den Bloomfilter. Das ist also ziemlich genau ein MiB (hier gesetzt: Byte == Oktet). Es ist zwar durch Kompression eine theoretische Ersparnis von rund 30% möglich, aber das ist erstens kompliziert und zweitens: Dekompression in Javascript? Das ist dann wirklich nur noch theoretisch, aber mit Sicherheit nicht mehr praktikabel.
Na, Best- und Worstcase werden schon meist angegeben, wenn sie sich
signifikant und begründbar unterscheiden. Ist eine wichtige
Entscheidungshilfe. BestCase hier oben ist ja schließlich O(1)!Bitte? Ne, dazu müßte eine Liste einelementig sein!
Nein, unter unseren Voraussetzungen wie gezeigt nicht.
Voraussetzungen waren:
In diesem Fall tritt BestCase ein falls S_1 != S_2, es ist nur noch ein Vergleich nötig. Gut, dazu müßte der generische Algorithmus etwas geändert werden, aber das schlägt sich nicht auf die Komplexität nieder.
Ein Bestcase ist wenn der letzte der einen Liste kleiner ist als der erste der anderen Liste (aufsteigend geordnet) und es deswegen keinen Schnitt gibt. Trotzdem mußt du erst zum Ende der einen Liste gelangen.
Bei unseren Bedingungen wäre das sogar WorstCase: beide Listen haben nicht nur die gleiche Anzahl Elemente, sondern sogar die gleichen Elemente: S_1 = S_2.
Allerdings würde ich hier wieder die Bedingungen ausnutzen können: da Alphabet und Länge der Listen bekannt sind, hier vor allem die Länge des Alphabets und das es keine Doubletten gibt, kann ich das gut mittels Divide&Conquer angehen. AverageCase also O(log(n)), BestCase O(1).
Ah, eine Bedingung habe ich ganz unterschlagen: als Elemente der Listen sind natürlich nur Elemente des Alphabets zulässig, keine Kombinationen. Das war mein Fehler, den mal wieder keiner gesehen hat.
Aber gut: Selbsterkenntnis ist der erste Weg zur Besserung, gelle? ;-)
Das hieß für mich immer O(n*log(n)), aber ich lasse mich gerne eines besseren belehren.
[Rolfs sorgfältige Erklärung]
Ah, danke, das hat geholfen!
Hoffe ich zumindest, aber das würde dann ja wieder an mir selber liegen, nicht an Deiner Erklärung.
so short
Christoph Zurnieden
Hi,
Denk an die frühen Assemblersprachen wo man vor jeder Operation erstmal die Werte in ein Register laden mußte,
Das gilt doch auch noch für die modernen Assemblersprachen?
Aua, aua, doch nich' gleich hauen!
ähm, bereits der 68000 kannte Speicheradressierungen für ADD und CMP, bei den Inteldinger kenn ich mich nicht aus (will es auch nicht :)
ja da habe ich was falsch abgeschrieben, Pidgeonsort schau ich mir gerne bald mal an :)
Ich putze mir gearde angelegentlich meine Sehhilfe, wenn Du zufällig gerade mit Telegraphenmasten winken solltest sehe ich das nicht.
Welcher Mast? Kein Mast!
Allerdings konnte ich zu Pidgeonsort nix googlen.
Obwohl ich in diesem Fall auch Bloomfilter spannend fände.
Ist in Arbeit, aber da es nun auch in Javascript funktionieren muß, ist das leider nicht ganz so einfach, wie das bischen Bitschuppserei in C.
Momentmal 1: Du versuchst bereits einen "Durchschnitt von n Listen" Algo mit Bloom Filtern zu realisieren?
Momentmal 2: Was geht in JS nicht? http://de.selfhtml.org/javascript/sprache/operatoren.htm#bits
Zudem wird der Bitstring, der den Bloomfilter darstellt verdammt lang. Bei 4 Hashfunktionen und den irgendwann einmal geschätzten 400 Einträgen bräuchte man
Oder sprichst du wieder vom Caching von Queries?
... für eine Fehlerrate von einem Promille 8172 Bits für den Bloomfilter. Das ist also ziemlich genau ein MiB (hier gesetzt: Byte == Oktet).
8172 Bits= 1MB??? Haben wir jetzt wieder ne Inflation wie in den 20ern ;)
Es ist zwar durch Kompression eine theoretische Ersparnis von rund 30% möglich, aber das ist erstens kompliziert und zweitens: Dekompression in Javascript?
Lauflängenkodierung oder so? Also in JS würd ich mir da keine Gedanken machen, wie willst du BTW einen 1 KB Bitstring im Quelltext verlustfrei in einem KB codieren?
Bitstream geht ja schlecht; bleibt nur Text! Und den würd ich sowieso gzippt ausliefern.
Entscheidungshilfe. BestCase hier oben ist ja schließlich O(1)!
Bitte? Ne, dazu müßte eine Liste einelementig sein!
Nein, unter unseren Voraussetzungen wie gezeigt nicht.
??? Gib mir mal bitte nen Algo der bei 2 Listen mit jeweils mehr als 1 Element den Durchschnitt ermittelt (Bestcase bitte angeben) und selbst bei einem Worstcase nur O(n) braucht.
In diesem Fall tritt BestCase ein falls S_1 != S_2, es ist nur noch ein Vergleich nötig. Gut, dazu müßte der generische Algorithmus etwas geändert werden, aber das schlägt sich nicht auf die Komplexität nieder.
Also du hattest früher sowas geschrieben wie
Worst Case:
S_1 = {a,b,c}
S_2 = {x,y,z}
...
Dadurch, das auch noch die Länge bekannt ist _und_ das zugrundeliegende Alphabet:
ax
??? wieso brauche ich nicht noch bx und cx zu prüfen, was hat das mit bekannter Länge und Alphabet zu tun???
[Rolfs sorgfältige Erklärung]
Ah, danke, das hat geholfen!
Hoffe ich zumindest, aber das würde dann ja wieder an mir selber liegen, nicht an Deiner Erklärung.
Ironie? ;)
Tschau
rolf
PS: Notationen: Ich bin Anhänger der alten Schule für die 1 KB=1024 Bytes und ein kg=1000 Gramm, abhängig davon ob K groß/kleingeschrieben wurde.
Hi,
Allerdings konnte ich zu Pidgeonsort nix googlen.
Warun das denn ... argh!
Das heißt natürlich Pigeonsort (Taubensortierung -> eine Taube pro Verschlag, jede weiß genau in welchen Verschlag)
Mensch, was peinlich wieder! Sorry.
Obwohl ich in diesem Fall auch Bloomfilter spannend fände.
Ist in Arbeit, aber da es nun auch in Javascript funktionieren muß, ist das leider nicht ganz so einfach, wie das bischen Bitschuppserei in C.
Momentmal 1: Du versuchst bereits einen "Durchschnitt von n Listen" Algo mit Bloom Filtern zu realisieren?
Nein, da keine Fehler genehmigt worden sind. Wäre aber bei unsortierten Listen eine gute Möglichkeit, wenn geringe Fehler erlaubt sind oder nur danach gesucht wird, ob _keine_ Schnittmenge existiert.
Momentmal 2: Was geht in JS nicht? http://de.selfhtml.org/javascript/sprache/operatoren.htm#bits
Ja, soviel geht natürlich (sonst hätte ich diese Idee auch sofort verworfen), aber es läßt sich von C aus nicht ganz 1:1 übersetzen. Mit ein wenig Mühe geht es aber doch und das meinte ich damit. Es sollte nach Möglichkeit jedesmal der gleiche Code sein, damit das Managment nicht ausufert.
Zudem wird der Bitstring, der den Bloomfilter darstellt verdammt lang. Bei 4 Hashfunktionen und den irgendwann einmal geschätzten 400 Einträgen bräuchte man
Oder sprichst du wieder vom Caching von Queries?
Ja. Kam nicht ganz raus? Sorry, keine Absicht. Manchmal verklemm ich mir einfach zuviel Platzverbrauch.
... für eine Fehlerrate von einem Promille 8172 Bits für den Bloomfilter. Das ist also ziemlich genau ein MiB (hier gesetzt: Byte == Oktet).
8172 Bits= 1MB??? Haben wir jetzt wieder ne Inflation wie in den 20ern ;)
Tut mir leid, aber da _konnte_ ich jetzt einfach nicht wiederstehen ;-)
Es ist zwar durch Kompression eine theoretische Ersparnis von rund 30% möglich, aber das ist erstens kompliziert und zweitens: Dekompression in Javascript?
Lauflängenkodierung oder so?
Nein, nur theoretische Kompresssion.
Also in JS würd ich mir da keine Gedanken machen, wie willst du BTW einen 1 KB Bitstring im Quelltext verlustfrei in einem KB codieren?
Indem ich etwas über einen KiB Bitstring in etwas unter eine KiB Bitstring komprimiere.
http://www.eecs.harvard.edu/~michaelm/NEWWORK/postscripts/cbf.pdf
Bitstream geht ja schlecht; bleibt nur Text! Und den würd ich sowieso gzippt ausliefern.
Ja, Base64-Codiert muß der natürlich werden, klar.
Entscheidungshilfe. BestCase hier oben ist ja schließlich O(1)!
Bitte? Ne, dazu müßte eine Liste einelementig sein!
Nein, unter unseren Voraussetzungen wie gezeigt nicht.
??? Gib mir mal bitte nen Algo der bei 2 Listen mit jeweils mehr als 1 Element den Durchschnitt ermittelt (Bestcase bitte angeben) und selbst bei einem Worstcase nur O(n) braucht.
Das habe ich weiter unten angegeben, das ich von eienr verkehrten Voraussetzung ausgegangen bin. Das heißt aber natürlich auch, das es genau diesen einen Fall auch tatsächlich gibt und mehr brauche ich ja für BestCase nicht.
Also du hattest früher sowas geschrieben wie
Worst Case:
S_1 = {a,b,c}
S_2 = {x,y,z}
...
Es liegt in dem, was durch die Ellipsis ersetzt wurde. Auf diesem langem Wege bin ich nämlcih dazu gekommen, dsa ich falsch lag und habe meine Meinung revidiert. Das das trotzdem ein Irrtum war, ich mir selebr ein Bein gestellt hatte, habe ich leider erst später erkannt.
Dadurch, das auch noch die Länge bekannt ist _und_ das zugrundeliegende Alphabet:
ax??? wieso brauche ich nicht noch bx und cx zu prüfen, was hat das mit bekannter Länge und Alphabet zu tun???
Wenn ich die Länge der Listen und des Alphabets kenne (und die veschlampte Bedingung, das alle Elemente auch Elemente aus dem Alphabet sein müssen und _nur_ das, also einzelne Buchstaben. Hätte ich die Beispiel anders gewählt, hätte ich den Fehler auch sofort bemerken können), kann ich aus dem erstem Vergleich 'ax' schon sehen, das nach x kein a mehr kommt. Da ich die Länge der Listen kenne und die Länge des Alphabets kann ich bei Länge drei feststellen, das nach a kein x mehr kommen kann. Auha, noch ein Fehler: ich müßte in dem Fall auch den letzten kontrollieren, klar. Also Mindestmaß sind zwei Vergleiche.
Da aber die Elemente natürlich nicht den Elementen im Alphabet entsprechen, sondern viel schlimmer Zeichenketten mit variablen Längen sind, die in variabler Zusammensetzung aus dem Alphabet gesetzt sind, stimmt das natürlich alles vorn und hinten nicht.
Bitet entschuldige meinen Betonkopf, aber am Ende hast Du ihn ja doch weich bekommen.
[Rolfs sorgfältige Erklärung]
Ah, danke, das hat geholfen!
Hoffe ich zumindest, aber das würde dann ja wieder an mir selber liegen, nicht an Deiner Erklärung.
Ironie? ;)
Nein, ganz und gar nicht!
Du hast das ganze in einer leicht andern Sichtweise dargestellt, als ich das kannte. Das hat mir dreidimensionale Sicht ermöglicht.
Da Du das ja kaum C&P von irgendwoher geklaut hast, hast Du da Arbeit reingesteckt, dafür muß ich mich doch bedanken, oder nicht?
PS: Notationen: Ich bin Anhänger der alten Schule für die 1 KB=1024 Bytes und ein kg=1000 Gramm, abhängig davon ob K groß/kleingeschrieben wurde.
Naja, mir gefällt das alles auch nicht immer, aber es ist numal so festgelegt vom OSI, ob's einem nun schmeckt oder nicht.
Aber man gewöhnt sich mit der Zeit daran ;-)
so short
Christoph Zurnieden
Hi,
Das heißt natürlich Pigeonsort (Taubensortierung -> eine Taube pro Verschlag, jede weiß genau in welchen Verschlag)
Mensch, was peinlich wieder! Sorry.
Also ich Legastheniker dachte auch dass sich die Tauben mit dg schreiben, es braucht also kein "Sorry". :)
Allerdings bleibt das googlen immer noch dürftig.
Momentmal 1: Du versuchst bereits einen "Durchschnitt von n Listen" Algo mit Bloom Filtern zu realisieren?
Nein, da keine Fehler genehmigt worden sind.
Genehmigt? Sprichst du von einem konkreten Projekt?
Wäre aber bei unsortierten Listen eine gute Möglichkeit, wenn geringe Fehler erlaubt sind oder nur danach gesucht wird, ob _keine_ Schnittmenge existiert.
Ja, bei unseren Postinglisten könnte man mit _zusätzlichen_ Bloomfiltern vielleicht sogar den durchschnittlichen Aufwand nochmals senken. Das Bloomfilterkonzept müsste allerdings scalierbar gemacht werden, da die Zahl der Einträge pro Liste ja nicht fix sind.
Ja, soviel geht natürlich (sonst hätte ich diese Idee auch sofort verworfen), aber es läßt sich von C aus nicht ganz 1:1 übersetzen. Mit ein wenig Mühe geht es aber doch und das meinte ich damit. Es sollte nach Möglichkeit jedesmal der gleiche Code sein, damit das Managment nicht ausufert.
Du kannst fehlende Funktionen oft gut mit Arrays realisieren. Z.B setBit(x) mit einem Array aus 32 Langwörtern die per OR verknüpft werden.
Indem ich etwas über einen KiB Bitstring in etwas unter eine KiB Bitstring komprimiere.
http://www.eecs.harvard.edu/~michaelm/NEWWORK/postscripts/cbf.pdf
Also neeee, da bin ich skeptisch. Die Kompressionsrate hochzutreiben in dem man die Zahl der Hashfkten reduziert ist doch reichlich ins Knie geschossen (habs nur überflogen aber trotzdem!). Da wähl ich die Parameter doch lieber gleich passend oder modifiziere das Konzept dahingehend dass ich von vornherein mit weniger Hashfkt weniger Platz brauche.
Bitstream geht ja schlecht; bleibt nur Text! Und den würd ich sowieso gzippt ausliefern.
Ja, Base64-Codiert muß der natürlich werden, klar.
Interessant, frisst JS von Haus aus Base64 Codierte Daten?
Da Du das ja kaum C&P von irgendwoher geklaut hast, hast Du da Arbeit reingesteckt, dafür muß ich mich doch bedanken, oder nicht?
Sagen wir mal ich hab Rechthaberei und Sturheit reingesteckt, dass kann ein ziemlicher Fluch sein, allem auf den Grund gehen zu wollen. ;|
Tschau
rolf
Hi
Wie ein Freund mir gerade erzählte soll in der neuen C'T eine sehr interessanten Volltextsuche auf Grundlage der Burroughs-Wheeler-Transformation beschrieben werden.
Tschau
rolf
Hi,
Also ich Legastheniker dachte auch dass sich die Tauben mit dg schreiben, es braucht also kein "Sorry". :)
Allerdings bleibt das googlen immer noch dürftig.
Ja, leider. Aber ich schau mal, was sich anderweitig so verbirgt. Zur Not bastel ich mal ein Beispiel.
Momentmal 1: Du versuchst bereits einen "Durchschnitt von n Listen" Algo mit Bloom Filtern zu realisieren?
Nein, da keine Fehler genehmigt worden sind.
Genehmigt? Sprichst du von einem konkreten Projekt?
Ja, von unserer Diskussion hier, warum?
Wenn da auch noch eine erlaubte Fehlermarge hineinspielt wird's mir zu komplex. Das könnte ich vielleicht noch implementieren, aber mit Sicherheit nicht mehr formal untermauern. Und empirische Beweisführung ist bei Mathematikern ja schon deutlich mehr als einfach nur verpönt, oder?
Wäre aber bei unsortierten Listen eine gute Möglichkeit, wenn geringe Fehler erlaubt sind oder nur danach gesucht wird, ob _keine_ Schnittmenge existiert.
Ja, bei unseren Postinglisten könnte man mit _zusätzlichen_ Bloomfiltern vielleicht sogar den durchschnittlichen Aufwand nochmals senken. Das Bloomfilterkonzept müsste allerdings scalierbar gemacht werden, da die Zahl der Einträge pro Liste ja nicht fix sind.
Muß nicht extra dazu gemacht werden, ist es ja schon in ausreichenden Grenzen. Die Fehlermarge steigt ja nicht so sonderlich steil, das man da nicht einiges verschmerzen könnte.
Ja, soviel geht natürlich (sonst hätte ich diese Idee auch sofort verworfen), aber es läßt sich von C aus nicht ganz 1:1 übersetzen. Mit ein wenig Mühe geht es aber doch und das meinte ich damit. Es sollte nach Möglichkeit jedesmal der gleiche Code sein, damit das Managment nicht ausufert.
Du kannst fehlende Funktionen oft gut mit Arrays realisieren. Z.B setBit(x) mit einem Array aus 32 Langwörtern die per OR verknüpft werden.
Zum Beipiel, ja.
Aber wenn man sich ein wenig an die 400 gecachten Seiten hält, kann man ganz gut mit fixen Werten arbeiten, die dann bei Bedarf händisch geändert werden. Sieht dann zwar alles wenig elegant aus, aber funktioniert.
Indem ich etwas über einen KiB Bitstring in etwas unter eine KiB Bitstring komprimiere.
http://www.eecs.harvard.edu/~michaelm/NEWWORK/postscripts/cbf.pdfAlso neeee, da bin ich skeptisch. Die Kompressionsrate hochzutreiben in dem man die Zahl der Hashfkten reduziert ist doch reichlich ins Knie geschossen (habs nur überflogen aber trotzdem!).
Nicht nur übefliegen, dsa war nämlich auch mein Fehler. Das funktioniert tatsächlich. Vorteil liegt aber weniger in der reduzierten Größe des resultierenden Bloomstrings - wird aber natürlich gerne mitgenommen, Bandbreite kostet schließlich Geld - sondern in der Reduktion der Anzahl der nötigen Hashfunktionen.
Ist für unseren Fall wenig von Belang, aber trotzdem recht interessant.
Da wähl ich die Parameter doch lieber gleich passend oder modifiziere das Konzept dahingehend dass ich von vornherein mit weniger Hashfkt weniger Platz brauche.
Genau das tut ja diese Kompression.
Bitstream geht ja schlecht; bleibt nur Text! Und den würd ich sowieso gzippt ausliefern.
Ja, Base64-Codiert muß der natürlich werden, klar.
Interessant, frisst JS von Haus aus Base64 Codierte Daten?
Nein, leider nicht jeder. Ist aber eine sehr billige Funktion, hüben wie drüben. Sind ja nur ein paar Bytes.
Da Du das ja kaum C&P von irgendwoher geklaut hast, hast Du da Arbeit reingesteckt, dafür muß ich mich doch bedanken, oder nicht?
Sagen wir mal ich hab Rechthaberei und Sturheit reingesteckt, dass kann ein ziemlicher Fluch sein, allem auf den Grund gehen zu wollen. ;|
Ja, das kann ich gut nachvollziehen.
Sehr gut sogar.
so short
Christoph Zurnieden
Hi Christoph,
Ja, von unserer Diskussion hier, warum?
Hmm, also dass es klappt ist IMHO klar, da es nur eine Verallgemeinerung von Hashes darstellt. Für mich bleibt nur offen, wie aufwendig die Hashfkt und das I/O kommen.
Wenn da auch noch eine erlaubte Fehlermarge hineinspielt wird's mir zu komplex. Das könnte ich vielleicht noch implementieren, aber mit Sicherheit nicht mehr formal untermauern. Und empirische Beweisführung ist bei Mathematikern ja schon deutlich mehr als einfach nur verpönt, oder?
Wär ja nicht empirisch sondern statistisch!
Im übrigen sind viele Hashfkt AFAIK nur empirisch durch Tests untermauert.
Wäre aber bei unsortierten Listen eine gute Möglichkeit, wenn geringe Fehler erlaubt sind oder nur danach gesucht wird, ob _keine_ Schnittmenge existiert.
Ja, bei unseren Postinglisten könnte man mit _zusätzlichen_ Bloomfiltern vielleicht sogar den durchschnittlichen Aufwand nochmals senken. Das Bloomfilterkonzept müsste allerdings scalierbar gemacht werden, da die Zahl der Einträge pro Liste ja nicht fix sind.
Muß nicht extra dazu gemacht werden, ist es ja schon in ausreichenden Grenzen. Die Fehlermarge steigt ja nicht so sonderlich steil, das man da nicht einiges verschmerzen könnte.
Hmm ja aber worauf ich hinaus will:
Wenn man die gleiche Hashfktnen und die gleiche Filterlänge hat reicht es die Filter aller Suchwörter miteinander zu schneiden um eine Abschätzung der Schnittmenge zu erhalten, im Extrem ist leerer Schnitt =erfolglose Suche.
Habe ich nun eine Liste mit 10000 Treffern ("Javascript") und eine mit 20 kommt man nur schwerlich mit nur einer Filterlänge aus.
Aber wenn man sich ein wenig an die 400 gecachten Seiten hält, kann man ganz gut mit fixen Werten arbeiten, die dann bei Bedarf händisch geändert werden. Sieht dann zwar alles wenig elegant aus, aber funktioniert.
Ehrlich gesagt, ich halte nen extra Cache für überflüssig wenn man schon den RAM-Hash H dafür hat. Obwohl wir verschiedene Sachen cachen, würd ich dann lieber RAM für die Posting-Listen aufwenden.
Und ob es sich lohnt 400 ganze HTML-Seiten im RAM zu halten, bezweifle ich, das kann aber letztlich nur eine Analyse der Useranfragen ergeben.
Andere Idee:
Wenn schon Lastverteilung gewünscht, dann lass doch gleich die Hashfunktionen des genesteten Hashes H x K_i auf dem Client berechnen.
Interessant, frisst JS von Haus aus Base64 Codierte Daten?
Nein, leider nicht jeder. Ist aber eine sehr billige Funktion, hüben wie drüben. Sind ja nur ein paar Bytes.
Um es mit JS zu decodieren? Lohnt sich das wirklich wenn ich den JS-Source auch gezipt ausliefern kann?
Was mich aktuell noch von einer Implementierung abhält ist die Tatsache dass die Aufgabe der Teilstringsuche noch nicht elegant gelöst ist. Was hilfts in nanosec
zu wissen wo überall ganze Wörter wie "Javascript" auftauchen, wenn ich die Platte nach Wörtern durchsuchen muss, die "Java" enthalten könnten?!?
Bye
rolf
Hi,
Ja, von unserer Diskussion hier, warum?
Hmm, also dass es klappt ist IMHO klar, da es nur eine Verallgemeinerung von Hashes darstellt. Für mich bleibt nur offen, wie aufwendig die Hashfkt und das I/O kommen.
Als Hashfunktion wird normalerweise ein kryptographischer Hash vorgeschlagen, Mitzenmacher hat z.B. DES genommen. Aufgrund der guten Verteilung der Bits im Hashwert selber kann man den dann tatsächlich "teilen".
Ich wollte MD5 nehmen, dafür gibt es ja bereits eine Javascriptimplementation.
Man könnte aber auch tatsächlich 4 einfache Hashfunktionen nehmen, da die Strings ja nur sehr kurz sind (über 30 Zeichen werden wohl kaum da rauskommen, wenn man Phrasen ignoriert. Aber nur, um mal eine Zahl zu nennen). Da kann dann man schon viermal drübergehen und ist evt immer noch biliger, als MD5.
Aber die Hashfunktionen sind vomprogrammiertechnischem Standpunkt her ziemlich beliebig autauschbar, das ist ein Sache von Minuten.
Wenn da auch noch eine erlaubte Fehlermarge hineinspielt wird's mir zu komplex. Das könnte ich vielleicht noch implementieren, aber mit Sicherheit nicht mehr formal untermauern. Und empirische Beweisführung ist bei Mathematikern ja schon deutlich mehr als einfach nur verpönt, oder?
Wär ja nicht empirisch sondern statistisch!
Nein, beim mir wäre es empirisch, statistisch wäre mir schon zu kompliziert ;-)
Im übrigen sind viele Hashfkt AFAIK nur empirisch durch Tests untermauert.
Ja, das ist mir auch aufgefallen. Mir ist sogar keine einzige bekannt, die tatsächlich berechnet wurde. Weder a priori noch a posteriori.
Hmm ja aber worauf ich hinaus will:
Wenn man die gleiche Hashfktnen und die gleiche Filterlänge hat reicht es die Filter aller Suchwörter miteinander zu schneiden um eine Abschätzung der Schnittmenge zu erhalten, im Extrem ist leerer Schnitt =erfolglose Suche.
Ja, könnte sich evt lohnen, insbesondere für die Phrasensuche. Braucht aber auch eine Menge Speicher, denn es wäre hier ein Bloomstring pro Liste erforderlich. Einfacher wäre es einen einzige Bloomstring für alle Suchwörter zu basteln, so das "not found" die DB gar nicht mehr belastet.
Habe ich nun eine Liste mit 10000 Treffern ("Javascript") und eine mit 20 kommt man nur schwerlich mit nur einer Filterlänge aus.
Deshalb braucht man ja auch soviel Platz dafür.
Aber wenn man sich ein wenig an die 400 gecachten Seiten hält, kann man ganz gut mit fixen Werten arbeiten, die dann bei Bedarf händisch geändert werden. Sieht dann zwar alles wenig elegant aus, aber funktioniert.
Ehrlich gesagt, ich halte nen extra Cache für überflüssig wenn man schon den RAM-Hash H dafür hat. Obwohl wir verschiedene Sachen cachen, würd ich dann lieber RAM für die Posting-Listen aufwenden.
Wie bereist vorgerechnet ist der Platzverbrauch nicht sonderlich hoch und mit vollständigem Caching sparst Du I/O auch vollständig ein. Manmüßte die genauen Zahlen haben, wieviele Leute überhaupt weiterblättern, und wieviele Prozent der Suche die vorgeschlagenen 400 Suchbegriffe ausmachen. Ohne diese Zahlen natürlich eine gewagte Hypothese, aber ich nehme doch an, das ich mit diesen 400 Begriffen schon so um die 95% abdecke und kaum einer weiterblättert.
Andere Idee:
Wenn schon Lastverteilung gewünscht, dann lass doch gleich die Hashfunktionen des genesteten Hashes H x K_i auf dem Client berechnen.
(D)DoS is' g'fährlich, wie der bayerischer Programmierer hier anmerken würde.
Interessant, frisst JS von Haus aus Base64 Codierte Daten?
Nein, leider nicht jeder. Ist aber eine sehr billige Funktion, hüben wie drüben. Sind ja nur ein paar Bytes.Um es mit JS zu decodieren? Lohnt sich das wirklich wenn ich den JS-Source auch gezipt ausliefern kann?
Achso, nein: ich muß ja verschiedene Bytes maskieren, da kann ich dann auch billiger gleich alle mit base64 maskieren. Ist dann zwar 30% länger, aber das macht den Hasen auch nicht mehr fett und fällt bei Auslieferung mit gzip eh wieder unter den Tisch.
Was mich aktuell noch von einer Implementierung abhält ist die Tatsache dass die Aufgabe der Teilstringsuche noch nicht elegant gelöst ist. Was hilfts in nanosec
zu wissen wo überall ganze Wörter wie "Javascript" auftauchen, wenn ich die Platte nach Wörtern durchsuchen muss, die "Java" enthalten könnten?!?
Für Teilstringfragen, vor allem solche "gierigen", ist das halt nicht geeignet, dafür gibt's dann andere Methoden.
Es ist nunmal ohne genaue Analysen der Suchanfragen nicht viel zu machen. Eine generelle, sozusagen optimale Lösung dürfte nicht existieren.
so short
Christoph Zurnieden
Hi,
Ich wollte MD5 nehmen, dafür gibt es ja bereits eine Javascriptimplementation.
gute Idee!
Nein, beim mir wäre es empirisch, statistisch wäre mir schon zu kompliziert ;-)
Jaja, Diplomingenieur, gell!?! ;)
Im übrigen sind viele Hashfkt AFAIK nur empirisch durch Tests untermauert.
Ja, das ist mir auch aufgefallen. Mir ist sogar keine einzige bekannt, die tatsächlich berechnet wurde. Weder a priori noch a posteriori.
Algorithmisch bekommt man halt nur einen Pseudozufall hin...
Habe ich nun eine Liste mit 10000 Treffern ("Javascript") und eine mit 20 kommt man nur schwerlich mit nur einer Filterlänge aus.
Deshalb braucht man ja auch soviel Platz dafür.
Hmm ... also ich denke, ich wüßte schon wie man das speichereffektiv hinbekäme (erspar mir Details :), bleibt aber die Frage ob sichs rechnet.
Achso, nein: ich muß ja verschiedene Bytes maskieren, da kann ich dann auch billiger gleich alle mit base64 maskieren. Ist dann zwar 30% länger, aber das macht den Hasen auch nicht mehr fett und fällt bei Auslieferung mit gzip eh wieder unter den Tisch.
achso klar man kann gleich in Base64 operieren...
Was mich aktuell noch von einer Implementierung abhält ist die Tatsache dass die Aufgabe der Teilstringsuche noch nicht elegant gelöst ist. Was hilfts in nanosec
zu wissen wo überall ganze Wörter wie "Javascript" auftauchen, wenn ich die Platte nach Wörtern durchsuchen muss, die "Java" enthalten könnten?!?Für Teilstringfragen, vor allem solche "gierigen", ist das halt nicht geeignet, dafür gibt's dann andere Methoden.
Obwohl man könnte zum Wort "Java" mit ablegen, wo es als Teilwort vorkommt. Dynamisch versteht sich. Auch häufige Phrasen (z.B. "Zu diesem Forum") könnten sich lohnen.
Tja, noch etwas was ich jetzt nicht durchrechne :)
Es ist nunmal ohne genaue Analysen der Suchanfragen nicht viel zu machen. Eine generelle, sozusagen optimale Lösung dürfte nicht existieren.
dito
Tschau
rolf
Hi,
Nein, beim mir wäre es empirisch, statistisch wäre mir schon zu kompliziert ;-)
Jaja, Diplomingenieur, gell!?! ;)
Nein, noch viel weiter weg, ganz andere Fakultät.
Ja, das ist mir auch aufgefallen. Mir ist sogar keine einzige bekannt, die tatsächlich berechnet wurde. Weder a priori noch a posteriori.
Algorithmisch bekommt man halt nur einen Pseudozufall hin...
Ja genau, und denn sollte man doch genau berechnen können, oder?
Hmm ... also ich denke, ich wüßte schon wie man das speichereffektiv hinbekäme (erspar mir Details :), bleibt aber die Frage ob sichs rechnet.
Da Du ziemlich viele zusätzliche Informationen einbauen möchtest kann eine Mindestmenge an Speicher pro Liste nicht unterschritten werden. Müßte man durchrechenen, aber ich glaube das wird einfach zuviel.
achso klar man kann gleich in Base64 operieren...
Könnte man auch, ja, aber das ist alles so klein udn vor allem statisch, das macht man einmal täglich nach base64 und dem Client ist das sowieso egal, das dürfte höchtens noch bei einme altem P1-200 o.ä. signifikant lahm werden, aber das würde auch wieder nicht auffallen, da MD5 ziemlich frißt. ICh habe leider keinen javascriptfähigen Browser auf meinem Laptop (ist ein P1-133er) sonst hätte ich das ma ausprobiert. Würde aber schon schätzen, dsa das die eine oder andere Sekunde dauert.
Obwohl man könnte zum Wort "Java" mit ablegen, wo es als Teilwort vorkommt. Dynamisch versteht sich. Auch häufige Phrasen (z.B. "Zu diesem Forum") könnten sich lohnen.
Das käme dann wieder auf eine statistische Auswertung der Suchbegriffe an.
so short
Christoph Zurnieden
Hi,
ich gratuliere zu diesem Rekord. So weit rechts eingerueckt habe ich bisher noch keine Beitraege gelesen.
Ist wohl wegen dem RSS-Feed passiert, was? ;-)
Gruss,
Ludger
Hi,
ich gratuliere zu diesem Rekord. So weit rechts eingerueckt habe ich bisher noch keine Beitraege gelesen.
das mag für dich gelten. aber gut zu wissen dass jmd mitliest und wir nicht zum mailen übergehen sollten.
Tschau
rolf
hängen wir doch noch einen dran...
hab mich heute schon den ganzen Tag gewundert, warum der HScrollbalken so lang ist, bis ich es rausgefunden habe...
Hi
hab mich heute schon den ganzen Tag gewundert, warum der HScrollbalken so lang ist, bis ich es rausgefunden habe...
Benutzt hier den keiner mehr den IE? Da wär sowas nicht passiert! ;)
Tschau
Rolf
Hi LanX,
hab mich heute schon den ganzen Tag gewundert, warum der HScrollbalken so lang ist, bis ich es rausgefunden habe...
Es ist frech, so weit rechts zu diskutieren!
Viele Grüße
Mathias Bigge
Hi Matthias,
Es ist frech, so weit rechts zu diskutieren!
Nicht wenn so viele mitlesen! :)
Du, Ludger, Lucas,...!
Cheers
Rofl
Hi,
Es ist frech, so weit rechts zu diskutieren!
Nicht wenn so viele mitlesen! :)
Du, Ludger, Lucas,...!
mitlesen ist wirklich zuviel gesagt.
Dass mein IE sowas noch rendern kann!
Gruss,
Ludger
Hi
Dass mein IE sowas noch rendern kann!
Schau ihn dir den Thread genau an, gleicht doch einer Tanne (die am 13.1 noch immer im Wohnzimmer steht)...
Vielleicht ist er ja was heiliges für deinen IE?
Tschau
rolf
Hi Christoph,
Jaja, Diplomingenieur, gell!?! ;)
Nein, noch viel weiter weg, ganz andere Fakultät.
Grundschullehramt Deutsch/Heimatkunde oder vielleicht Körperpflege an der TU Darmstadt? *fg*
Wer nicht rechnet sondern nachschlägt und ausprobiert ist für mich ein Ingenieur. So wie die meisten Infe ;)
Ja, das ist mir auch aufgefallen. Mir ist sogar keine einzige bekannt, die tatsächlich berechnet wurde. Weder a priori noch a posteriori.
Algorithmisch bekommt man halt nur einen Pseudozufall hin...
Ja genau, und denn sollte man doch genau berechnen können, oder?
Hmm, nicht meine Baustelle ... aber man kann sicher berechnen, dass die Verteilung einigermaßen "gut" ist. Um z.B. im Falle von Hashes Kollisionen zu vermeiden, sollte sich die erzeugte Folge von Zufallszahlen aber nicht wiederholen, dass ist bei algorithmischen Generatoren IMHO kaum zu leisten. Selbst wenn man echte physikalische Zufallszahlen als Saat einbindet, bleibt das Problem, dass deren Menge in einem endlichen Speicher auch nur endlich sei kann, und man deswegen wiederholen muss.
http://de.wikipedia.org/wiki/Zufallsgenerator
Wenn wir da weiterdenken, streifen wir aber schon Philosophie und Physik, und streiten bald über Einsteins "Gott würfelt nicht".
Hmm ... also ich denke, ich wüßte schon wie man das speichereffektiv hinbekäme (erspar mir Details :), bleibt aber die Frage ob sichs rechnet.
Da Du ziemlich viele zusätzliche Informationen einbauen möchtest kann eine Mindestmenge an Speicher pro Liste nicht unterschritten werden. Müßte man durchrechenen, aber ich glaube das wird einfach zuviel.
naja, mit _normalen_ Bloomfiltern hat man sowieso kaum einen Gewinn, deswegen sollte man da schon die Theorie verinnerlichen und was angepasstes creieren. Schau mal:
"A Bloom filter with 1% error and an optimal value of m, on the other hand, requires only about 9.6 bits per element" http://en.wikipedia.org/wiki/Bloom_filter#Space_and_time_advantages
Ich sag mal mit durchschnittlich 9.6 Bits kodiere ich die ganze Postingliste mit 0% Fehler. (diesmal bitte keine Bierkiste :)
Und ob das bei deinem Caching hilft?
Schau mal 400 gecachte Begriffe a ~10 Buchstaben
=> 4 KB ~ gzipt 400 B , maximal 800 B.
400 *9.6 bits ~ 460 Bytes und zippen kann wg der Entropie auch nix helfen.
Zeitvorteil? beim Bloomfilter müssen 4-5 Hashfkt berechnet werden, steckst du statt dessen alles gleich in einen großen Hash kommst du IMHO schneller hin. Da würd sich wohl schon der normale JS-Hash rechnen.
achso klar man kann gleich in Base64 operieren...
Könnte man auch, ja, aber das ist alles so klein udn vor allem statisch, das macht man einmal täglich nach base64 und dem Client ist das sowieso egal, das dürfte höchtens noch bei einme altem P1-200 o.ä. signifikant lahm werden, aber das würde auch wieder nicht auffallen, da MD5 ziemlich frißt.
Bin verwirrt, willst du die Daten in JS nur in Base64 halten und die algorithmen daran anpassen, oder sollen die Daten jedesmal konvertiert werden?
ICh habe leider keinen javascriptfähigen Browser auf meinem Laptop (ist ein P1-133er) sonst hätte ich das ma ausprobiert. Würde aber schon schätzen, dsa das die eine oder andere Sekunde dauert.
also auf meinem P2/330 MHZ funktioniert MD5 so fix, dass es auch auf einem P1 kaum einen User stören sollte. http://aktuell.de.selfhtml.org/artikel/javascript/md5/#a5
Das käme dann wieder auf eine statistische Auswertung der Suchbegriffe an.
tja ich bleib dabei eine "optimale" Lösung müßte mit n-grammen arbeiten.
Weiß man eigentlich wie google es macht?
BTW: Würde google anbieten suchergebnisse nach Anchors zu gliedern, bräuchten wir hier keine eigene Suchmaschine...
Tschau
rolf
Hi,
Jaja, Diplomingenieur, gell!?! ;)
Nein, noch viel weiter weg, ganz andere Fakultät.
Grundschullehramt Deutsch/Heimatkunde oder vielleicht Körperpflege an der TU Darmstadt? *fg*
Komm Du mir mal unter die Faust^WFinger!
Meint der doch glatt, ich wär' Grundschullehrer!
Seh' ich etwa so aus?
Ts, ts, ts!
;-)
Ja, das ist mir auch aufgefallen. Mir ist sogar keine einzige bekannt, die tatsächlich berechnet wurde. Weder a priori noch a posteriori.
Algorithmisch bekommt man halt nur einen Pseudozufall hin...
Ja genau, und denn sollte man doch genau berechnen können, oder?
Hmm, nicht meine Baustelle ...
Schad'!
Da hat man mal eine Mathematiker an der Hand ... ;-)
aber man kann sicher berechnen, dass die Verteilung einigermaßen "gut" ist. Um z.B. im Falle von Hashes Kollisionen zu vermeiden, sollte sich die erzeugte Folge von Zufallszahlen aber nicht wiederholen, dass ist bei algorithmischen Generatoren IMHO kaum zu leisten. Selbst wenn man echte physikalische Zufallszahlen als Saat einbindet, bleibt das Problem, dass deren Menge in einem endlichen Speicher auch nur endlich sei kann, und man deswegen wiederholen muss.
Man kann sie aber erstaunlich stark verdünnen und so auch mit sehr wenig echtem Zufall (z.B. thermisches Rauschen der Soundkarteneingänge) erfolgreich füttern.
Denn es gilt ja die Entropie
E = -p(0) log(p(0)) - p(1) log(p1)
also kann man mit einer anderen unabhängigen(!) Folge und Modulko-2 Addition (XOR) eine andere Folge herstellen mit (der Übersichtlichkeit halber mit x=p(0) und 1-x=p(1))
E_1 - E_2 = -(x^2 + (1-x)^2) log(x^2 + (1-x)^2)
-2x(1-x) log(2x(1-x))
+x log(x) + (1-x) log(1-x)
(Au Mann, na hoffentlich stimmt da auch alles, bitte um evt Korrektur)
http://de.wikipedia.org/wiki/Zufallsgenerator
Wenn wir da weiterdenken, streifen wir aber schon Philosophie und Physik, und streiten bald über Einsteins "Gott würfelt nicht".
Würde ichmich nihct daruf einlassen, ich bin zum Schluß gekommen, das das nicht nur nicht entscheidbar ist sondern zudem auch völlig egal. Ist auch nur ein Ding vorherbestimmt gibt es eh keinen freien Willen, gibt es jedoch eine freien Willen ist auch nichts vorherbestimmt.
"A Bloom filter with 1% error and an optimal value of m, on the other hand, requires only about 9.6 bits per element" http://en.wikipedia.org/wiki/Bloom_filter#Space_and_time_advantages
Ich sag mal mit durchschnittlich 9.6 Bits kodiere ich die ganze Postingliste mit 0% Fehler. (diesmal bitte keine Bierkiste :)
1% ist aber recht viel, ein Promille ist da schon realistischer. Kostet aber natürlich auch nicht viel mehr pro Element, das ist wohl wahr. (0% ist sehr schwierig, da müßten nicht nur alle Hashfunktion minimal perfekt sein, sondern auch alle Permutationen.)
Ah, BTW: habe da 'was gefunden (zum Thema: "Was es nicht so alles im Netz zu finden gibt"): http://www.cc.gatech.edu/fac/Pete.Manolios/bloom-filters/calculator.html
Und ich Idiot fummel hier mit Stift, Papier und Taschenrechner rum ;-)
Und ob das bei deinem Caching hilft?
Schau mal 400 gecachte Begriffe a ~10 Buchstaben
=> 4 KB ~ gzipt 400 B , maximal 800 B.400 *9.6 bits ~ 460 Bytes
Aber wie gesagt: 0% gibt's hier nur mit minimal perfektem Hash. Und dann kannst Du Dir die Mühe mit dem Bloomfilter eh sparen und gleich eine normale Hastabelle nehmen und als fertiges Javascript-Array mitgeben.
Mmh ...
Auch keine schlechte Idee.
Clientseitig ein Javascript-Array, das die Suchworte als Strings aufnimmt, das wären bei angenommen 10 Buchstaben (Oktets, bei Multibitzeichensätzen enstpr anpassen) rund 4.000 Oktets plus 400*Hashwert (2^16 reicht, das sind zwei Oktets, drei bei Base64, macht 1.200 Oktets) sind bei angenommen Oktets=Byte runde fünf Kilobyte. Da könnte man das sogar ganz einfach machen und den Server gar nicht mehr belasten und direkt auf Pfade mappen. Macht dann vielleicht 20 KiB und da es einfache Buchstaben sind, läßt es sich hervorragend zippen und wenn da nur nachgeladen wird, wenn Javascript eingeschaltet ist (die üblichen Tricks halt), dann könnte man einen wirtschaftlichen Nutzen erwarten.
Man könnte evt sogar ein paar Spielereien mit xmlHttpRequest() anstellen.
und zippen kann wg der Entropie auch nix helfen.
Nein, tut mir leid, _so_ leicht führst Du mich nicht auf's Glatteis, ich hab' schon bemerkt, das Du hier die Informationsbits _netto_ zugrunde gelegt hast ;-)
Bin verwirrt, willst du die Daten in JS nur in Base64 halten und die algorithmen daran anpassen, oder sollen die Daten jedesmal konvertiert werden?
Würden jedesmal konvertiert werden. "Jedesmal" ist auf dem Server "nach jedem Update des Archivs" und nur auf dem Client wirklich jedesmal. Dürfte aber deutlich billiger sein als mühseliges Anpassen der Hashfunktionen
also auf meinem P2/330 MHZ funktioniert MD5 so fix, dass es auch auf einem P1 kaum einen User stören sollte.
Und wer hat auch noch so ein altes Dingen ;-)
Das käme dann wieder auf eine statistische Auswertung der Suchbegriffe an.
tja ich bleib dabei eine "optimale" Lösung müßte mit n-grammen arbeiten.
Naja, wollen's wegen der Anführungstriche einmal so annehmen.
Weiß man eigentlich wie google es macht?
Das erfährts Du nur mit 50%+1 an stimmberechtigten Aktien ;-)
Aber im Ernst: da ist natürlich viel Gehrinschmalz reingesteckt worden, aber im Grunde kochen die auch nur mit Wasser: massivem Hardwareeinsatz.
Das Gebiet "Suche" ist derart gut bekannt, das es für weiter signifikante Fortschritte der hellsten Köpfe bedarf. Deren Auswahl unter den Bewerbern soll _extrem_ scharf sein, einige berichteten von über 20 Interviews und wurden dann doch nicht genommen. Einzige Alternative ist also massiver Hardwareeinsatz.
BTW: Würde google anbieten suchergebnisse nach Anchors zu gliedern, bräuchten wir hier keine eigene Suchmaschine...
Wenn man denen das bezahlt machen die das sicherlich gerne.
so short
Christoph Zurnieden
Hi,
Meint der doch glatt, ich wär' Grundschullehrer!
Seh' ich etwa so aus?
Ne eher wie ein Körperpfleger! ;)
"A Bloom filter with 1% error and an optimal value of m, on the other hand, requires only about 9.6 bits per element" http://en.wikipedia.org/wiki/Bloom_filter#Space_and_time_advantages
Ich sag mal mit durchschnittlich 9.6 Bits kodiere ich die ganze Postingliste mit 0% Fehler. (diesmal bitte keine Bierkiste :)
1% ist aber recht viel, ein Promille ist da schon realistischer.
nee, Eigentoor, es ist sogar schlimmer, sofern dein Bloomfiltercaculator was taugt:
"Below, m denotes the number of bits in the Bloom filter,
n denotes the number of elements inserted into the Bloom filter,
k represents the number of hash functions used, and
p denotes the false positive rate.
You have given a value of 400 for n and 0.01 for p.
The smallest m is 3838; k is 7 and p is 0.009989870082546317"
ACHT HUNDERT BYTES!!!
»»http://www.cc.gatech.edu/fac/Pete.Manolios/bloom-filters/calculator.html
Kostet aber natürlich auch nicht viel mehr pro Element, das ist wohl wahr. (0% ist sehr schwierig, da müßten nicht nur alle Hashfunktion minimal perfekt sein, sondern auch alle Permutationen.)
für 0% kann man keine Bloomfilter nehmen weil die grundsätzlich verlustbehaftet sind, selbst wenns im Nanobereich läge.
Und ob das bei deinem Caching hilft?
Schau mal 400 gecachte Begriffe a ~10 Buchstaben
=> 4 KB ~ gzipt 400 B , maximal 800 B.400 *9.6 bits ~ 460 Bytes
Aber wie gesagt: 0% gibt's hier nur mit minimal perfektem Hash. Und dann kannst Du Dir die Mühe mit dem Bloomfilter eh sparen und gleich eine normale Hastabelle nehmen und als fertiges Javascript-Array mitgeben.
Mmh ...
Auch keine schlechte Idee.
Das war ja auch jetzt meine Idee ... naja macht nix. Steck deinen 400er-Cache in nen normalen JS-Hash ohne propietäre Hashfkt, das reicht doch dicke!
und zippen kann wg der Entropie auch nix helfen.
Nein, tut mir leid, _so_ leicht führst Du mich nicht auf's Glatteis, ich hab' schon bemerkt, das Du hier die Informationsbits _netto_ zugrunde gelegt hast ;-)
hmm, ne Brutto,
400 (einträge) *10 Bytes /5-10 (gzip)=800-400 Bytes
oder was? Ach so, nee! - dein _Bloomfilter_ läßt sich nicht mehr zippen war die Aussage. Ein optimal ausgelasteter Bloomfilter hat AFAIK jedes 2 Bit zufällig gesetzt.
Das Gebiet "Suche" ist derart gut bekannt, das es für weiter signifikante Fortschritte der hellsten Köpfe bedarf. Deren Auswahl unter den Bewerbern soll _extrem_ scharf sein, einige berichteten von über 20 Interviews und wurden dann doch nicht genommen. Einzige Alternative ist also massiver Hardwareeinsatz.
ui dann will ich hier öffentlich nicht mehr Tricks verraten ;)
Im ernst die Leute dürften dann in dem Bereich promoviert haben.
BTW: Würde google anbieten suchergebnisse nach Anchors zu gliedern, bräuchten wir hier keine eigene Suchmaschine...
Wenn man denen das bezahlt machen die das sicherlich gerne.
Phh, wer will den Usern verbieten google zu nutzen? Direkt linken von selfhtml.org wär nicht gartis drin, aber wenn google es leistete würdens die Self-User es von sich aus auch anwenden.
Tschau
rolf
PS: Wird einsam hier unten, meinst du es liest noch jmd mit oder sollen wir leiber aufs mailen ausweichen?
Auf der Suche nach Material zu einer Suchmaschine mit Burrows-Wheeler-Transformation (so wirds richtig geschrieben, hat auch keienr bemerkt) bin ich auf folgende Diss gestoßen:
Interessanterweise benutzt er auch einen einfach verschachtelten Hash, die Idee ist also gar nicht sooo exotisch.
Soweit ich sehe ist der Unterschied hier, dass er keine unabhängigen Funktionen braucht sondern unterschiedliche Wortbestandteile einfüttert.
Er spaötet dazu die Suffizes der Wörter ab, macht sich also die Struktur der Sprache zu nutze.
BTW: Habe im Netz gelesen dass bei einer Codierung bei der Wörter im ersten Schritt in Prefix, Stamm, Suffix zerlegt werden, und anschließend die n-gramme des Stammes Huffmancodiert werden, eine Kompresionsrate von gigantischen 1.5 Bits/Character der englischen Sprache erzielt werden können. WOW!
Tschau
rolf
Hi,
Auf der Suche nach Material zu einer Suchmaschine mit Burrows-Wheeler-Transformation (so wirds richtig geschrieben, hat auch keienr bemerkt)
Es sah merkwürdig aus, ich konnte aber auch nicht sagen warum ;-)
Interessanterweise benutzt er auch einen einfach verschachtelten Hash, die Idee ist also gar nicht sooo exotisch.
Hat ja auch keiner behauptet und es war auch sehr wahrscheinlich, das das schonmal jemand untersucht hatte.
Aber ohen willige Assis, die man losschicken kann nach Literatur zu suchen ist so eine Suche ein müßiges Unterfangen.
Aber da ich mich da jetzt eh durchwühlen mußte: hat mit unserem Problem und Deinem Vorschlag nur sehr am Rande etwas zu tun. Es geht darum den längsten passenden String zu finden, dafür müssen natürlich alle Fundstücke miteinander verglichen werden. Da ist so eine zweistufige Hashtabelle natürlich nicht verkehrt. Aber nutzt das auch für unseren Zweck?
Soweit ich sehe ist der Unterschied hier, dass er keine unabhängigen Funktionen braucht sondern unterschiedliche Wortbestandteile einfüttert.
Das ist aufgrund des riesigen Alphabets der Silbenschrift nötig sowie günstiger bei DNA-Sequenzen (da gibt es keine Wörter im eigentlichem Sinne wenn auch das Alphabet dafür recht kurz ist.)
Er spaötet dazu die Suffizes der Wörter ab, macht sich also die Struktur der Sprache zu nutze.
Äh, nein, so ein Suffix-Tree hat mit Silben im grammatikalischem Sinne nichts zu tun und wurde in diesem Fall sogar benutzt eben _weil_ die Sprache _nicht_ so einfach geparsed werden kann. Und bei DNA hast Du ja erst gar keine Worttrenner, da wird's dann doch recht heftig, vor allem da unterschiedliceh Abstände auftreten. Um Verwandschaften zu erkennen muß man nach "longest common substrings" suchen. So ein LCB ist z.B. bei "aaawbbbommrjjjjtlll" und "w4o1r1t11" "wort". Ja, genau: so wie bei CSI beschrieben funktioniert es nicht und dauert vor allem nicht bloß ein paar Minuten sondern eher ein paar Tage ;-)
BTW: Habe im Netz gelesen dass bei einer Codierung bei der Wörter im ersten Schritt in Prefix, Stamm, Suffix zerlegt werden, und anschließend die n-gramme des Stammes Huffmancodiert werden, eine Kompresionsrate von gigantischen 1.5 Bits/Character der englischen Sprache erzielt werden können. WOW!
Ja, die englische Sprache läßt sich wunderbar zerlegen. Ist eine Besonderheit der englischen Sprache, das funktioniert so nirgendwo anders, höchstens noch im lateinischem o.ä. Sprachen. Zudem ist sie auch noch recht redundant auf Bitebene, da das Alphabet ein klein bisschen weniger als als 6-Bit benötigt, das japanische aber z.B. mehr als 15-Bit (soviele Zeichen werden natürlich nicht im täglichem Umgang benutzt, aber es sind wirklich einige zehntausend). Auch werden Großbuchstaben sehr selten benutzt, die Worte sind recht kurz usw. Das grammtikalische Regelwerk basiert im Englischem zum Hauptteil auf zwei Sprachen, im Deutschen sind es da schon erheblich mehr.
Selbst wenn wir den Aufwand nicht scheuten kämen wir im Deutschen wohl nicht unter rund 1,7 Bit/Zeichen (sieht man auch bei Übersetzungen vom Englischem in's Deutsche: die sind in der Regel runde 10% länger.)
so short
Christoph Zurnieden
Hi,
mit etwas Verspätung mir fesselt grad ein Virus in der horizontalen.
Aber da ich mich da jetzt eh durchwühlen mußte:
das wollte ich nicht! :(
hat mit unserem Problem und Deinem Vorschlag nur sehr am Rande etwas zu tun.
Stimmt. Ich versuche auch den möglichen Background zum ct-Artikel zu finden (den ich wg Bettruhe auch noch nicht lesen konnte).
Ich hatte auch nen sehr interessanten Link zu dem Thema den ich jetzt nicht mehr finde ... ahh wozu gibts CTRL-H ... moment ... et voila ... http://blog.csdn.net/jiangtao/archive/2004/04/08/270.aspx
Ich denke der Zusammenhang zu unserem Problem ist, dass im Allgemeinen keine ganzen Wörter gesucht werden, sondern auch submatches!
Der Gag ist, die BWT sortiert die Buchstaben eines Textes so um dass bestimmte Ordnungstrukturen erhalten bleiben, die eine sehr schnelle Suche von Teilstrings erlaubt. Und nebenbei läßt sich BWTransformierter Text bis fast ans theoretische Optimum komprimieren.
In wie weit das aber zu meiner Hash-in-Hash-Lösung kombinierbar ist, die IMHO die beste Performance bei Ganzwörtern liefern sollte, weiß ich noch nicht.
Das ist aufgrund des riesigen Alphabets der Silbenschrift nötig sowie günstiger bei DNA-Sequenzen (da gibt es keine Wörter im eigentlichem Sinne wenn auch das Alphabet dafür recht kurz ist.)
Gings in dem Artikel nur um ostasiatische Texte? :(
Selbst wenn wir den Aufwand nicht scheuten kämen wir im Deutschen wohl nicht unter rund 1,7 Bit/Zeichen (sieht man auch bei Übersetzungen vom Englischem in's Deutsche: die sind in der Regel runde 10% länger.)
naja dass ist kein Argument gegen eine bessere Kompression im Deutschen insbesondere weil die englische Orthographie viel unregelmäßiger ist als unsere und das größte Vokabular nach dem Chinesischen beinhaltet.
habe die Ehre...
rolf
Hi,
mit etwas Verspätung mir fesselt grad ein Virus in der horizontalen.
Ähm ... Deine sexuellen Präferenzen interessieren mich jetzt eher weni... achso, krank isser, dann mal Gesundheit!
Aber da ich mich da jetzt eh durchwühlen mußte:
das wollte ich nicht! :(
Na, waren gerade mal 150 Seiten, das halbe Stündchen habe ich denn auch noch ;-)
hat mit unserem Problem und Deinem Vorschlag nur sehr am Rande etwas zu tun.
Stimmt. Ich versuche auch den möglichen Background zum ct-Artikel zu finden (den ich wg Bettruhe auch noch nicht lesen konnte).
Macht nix, ich habe es noch nicht einmal geschafft mir eine ct zu besorgen.
Ich hatte auch nen sehr interessanten Link zu dem Thema den ich jetzt nicht mehr finde ... ahh wozu gibts CTRL-H ... moment ... et voila ... http://blog.csdn.net/jiangtao/archive/2004/04/08/270.aspx
Mir fehlen für xpdf die richtigen Fonts (nein, ich habe nur Freefont nicht richtig eingebunden bekommen oder das ist zu alt) aber ich werde das dumme Gefühl nicht los, das das einer seiner Studenten ist?
Aber ist ja auch egal, tut hier nix zur Sache.
Die untersuchte Materie ist der Umstand, das sich alle Kompressions- und Suchalgorithmen auf ein Sortierproblem zurückführen lassen. Das ist hochinteresant aber leider nur noch theoretisch von Belang, da es nicht mehr wichtig ist, die Leistung eines Einzelnen optimal einzusetzen, sondern die Aufgabe optimal zu verteilen.
Es ist zwar durchaus von Belang für den Selfserver hier - ist ja im Grunde nur eine einzelne Maschine und Verteilungoptimierung lohnt nur für Knotenmengen >> eine Handvoll - aber der Vorgang ist sehr komplex und müßte von Grund auf gebastelt werden. Lohnt das?
Ich denke der Zusammenhang zu unserem Problem ist, dass im Allgemeinen keine ganzen Wörter gesucht werden, sondern auch submatches!
Ja, das ergibt sich natürlich schon zwingend.
Der Gag ist, die BWT sortiert die Buchstaben eines Textes so um dass bestimmte Ordnungstrukturen erhalten bleiben, die eine sehr schnelle Suche von Teilstrings erlaubt. Und nebenbei läßt sich BWTransformierter Text bis fast ans theoretische Optimum komprimieren.
Dabei geht aber, und das macht die Zusammenfassung auf Deinem Link oben nochmal besonders deutlich, der Ort verloren.
Mmh ... Heisenberg in der Informationstheorie? ;-)
Ist der wichtig? Wenn nicht, wäre es ein relativ bequemer Ansatz, wenn doch wird die Komplexität stark erhöht bzw der Speicherbedarf.
In wie weit das aber zu meiner Hash-in-Hash-Lösung kombinierbar ist, die IMHO die beste Performance bei Ganzwörtern liefern sollte, weiß ich noch nicht.
Da Hashtables (die in den USA übrigens patentiert sind) in O(1) was finden, kann das vorgeschaltet werden.
Oben vorgestellte Methode hat zwar eine gute Speichereffiziens für "vorgesuchte" Volltextsuche dürfte aber auch noch zu groß sein und das Budget sprengen.
Gut, _sowas_ ist natürlich kein Argument, klar ;-)
Das ist aufgrund des riesigen Alphabets der Silbenschrift nötig sowie günstiger bei DNA-Sequenzen (da gibt es keine Wörter im eigentlichem Sinne wenn auch das Alphabet dafür recht kurz ist.)
Gings in dem Artikel nur um ostasiatische Texte? :(
Nein, aber er entstand aus dem Problem, das genau für diese beiden Anwendungen (Silbenschrift/DNA) die gängigen Methoden zur Textsuche kläglich versagen. Alle Tests zielten deshalb auch daraufhin, bei aller Optimierung keine andere Anwendungsmöglichkeit schlechter werden zu lassen. Das die dabei auch eien Farbauffrischung bekamen war zwar nicht beabsichtigt, wurde aber durchaus und lautstark begrüßt.
Selbst wenn wir den Aufwand nicht scheuten kämen wir im Deutschen wohl nicht unter rund 1,7 Bit/Zeichen (sieht man auch bei Übersetzungen vom Englischem in's Deutsche: die sind in der Regel runde 10% länger.)
naja dass ist kein Argument gegen eine bessere Kompression im Deutschen insbesondere weil die englische Orthographie viel unregelmäßiger ist als unsere und das größte Vokabular nach dem Chinesischen beinhaltet.
Meines Wissens ist das Vokabular der Chinesen nicht überdurchschnittlich groß? Die englische Orthographie ist auch nicht sonderlich unregelmäßig. Sie enstand aus zwei unterschiedlichen Stämmen, deshalb sieht das mitunter merkwürdig aus, ist aber recht logisch geblieben. Das kann man vom Deutschen nicht gerade behaupten, das ist ein aus allen Ecken und Enden zusammengewürfelter Mischmasch. Das war auch ein Grund zur Erfindung des Hochdeutschen gewesen. Und wenn sich damals nicht mal zwei Leute verkracht hätten würden wir heute französisch quasseln ;-)
so short
Christoph Zurnieden
Hi,
mit etwas Verspätung mir fesselt grad ein Virus in der horizontalen.
Ähm ... Deine sexuellen Präferenzen interessieren mich jetzt eher weni... achso, krank isser, dann mal Gesundheit!
*LOL*
Ich warne davor eine dieser Viren-Schlampen näher kennen zulernen, die versuchen einen doch nur auszunutzen ;)
Mir fehlen für xpdf die richtigen Fonts (nein, ich
hmm ich dachte da ne HTML-Seite gesehen zu haben...
leider nur noch theoretisch von Belang, da es nicht mehr wichtig ist, die Leistung eines Einzelnen optimal einzusetzen, sondern die Aufgabe optimal zu verteilen.
Es ist zwar durchaus von Belang für den Selfserver hier - ist ja im Grunde nur eine einzelne Maschine und Verteilungoptimierung lohnt nur für Knotenmengen >> eine Handvoll - aber der Vorgang ist sehr komplex und müßte von Grund auf gebastelt werden. Lohnt das?
Ich denke es lohnt sich generell sich mit dem Ansatz zu beschäftigen, ob sich das für den Selfserver auswirkt
weiß ich nicht, ist das unser Schwerpunkt oder eher die Theorie?
Ich denke der Zusammenhang zu unserem Problem ist, dass im Allgemeinen keine ganzen Wörter gesucht werden, sondern auch submatches!
Ja, das ergibt sich natürlich schon zwingend.
eben.
Der Gag ist, die BWT sortiert die Buchstaben eines Textes so um dass bestimmte Ordnungstrukturen erhalten bleiben, die eine sehr schnelle Suche von Teilstrings erlaubt. Und nebenbei läßt sich BWTransformierter Text bis fast ans theoretische Optimum komprimieren.
Dabei geht aber, und das macht die Zusammenfassung auf Deinem Link oben nochmal besonders deutlich, der Ort verloren.
AFAIK, kannst du die Länge des BWTransformierten Intervalls einstellen, je länger umso besser die Kompression.
Hingegen nur ganze Postings oder Threads zu nehmen würde zwar die Kompression herabsetzen, dafür aber aussagefähige Treffer liefern.
Mmh ... Heisenberg in der Informationstheorie? ;-)
Natürlich! Ganz ohne Ironie!
Meines Wissens ist das Vokabular der Chinesen nicht überdurchschnittlich groß?
Hmmm ... Hörensagen ... kann jetzt keinen Beleg dafür finden, insbesondere, weil die Definition von Chinesisch wg der viele Einzelsprachen und Dialekte schwammig ist.
Hingegen beim Englischen ...
"English is noted for the vast size of its active vocabulary and its fluidity. English easily accepts technical terms into common usage and imports new words which often come into common usage" http://en.wikipedia.org/wiki/English_language#Vocabulary
Die englische Orthographie ist auch nicht sonderlich unregelmäßig. Sie enstand aus zwei unterschiedlichen Stämmen, deshalb sieht das mitunter merkwürdig aus, ist aber recht logisch geblieben.
HA!
"English spelling is often considered to be one of the most difficult to learn of any language that uses an alphabet" http://en.wikipedia.org/wiki/English_language#Writing_system
Das kann man vom Deutschen nicht gerade behaupten, das ist ein aus allen Ecken und Enden zusammengewürfelter Mischmasch. Das war auch ein Grund zur Erfindung des Hochdeutschen gewesen.
Deutsch wird schon sehr phonetisch geschrieben, z.B. Spanisch ist in der Beziehung schon nahe am Optimum.
http://forum.de.selfhtml.org/archiv/2004/8/t86714/#m516043
Ich glaube du sprichst aber hier eher von den Problemen der Rechtschreibung (Groß/Klein, getrennt/zusammen, ß/ss) die das Englische nicht hat, das macht sich aber IMHO bei einer Kompression kaum bemerkbar.
Eher Nachteilig könnte die von dir erwähnten 10% längeren Texte sein, da IMHO im deutschen präziser/pedantischer gesprochen wird, wo dem Engländer der Kontext bereits zur Klärung aussreicht.
Und wenn sich damals nicht mal zwei Leute verkracht hätten würden wir heute französisch quasseln ;-)
Hä? Meinst du jetzt Karl den Kahlen und Anverwandte? Oder Friedrich II und Voltaire?
Gewagte Thesen! :)
Tschau
rolf
Hi,
Mir fehlen für xpdf die richtigen Fonts (nein, ich
hmm ich dachte da ne HTML-Seite gesehen zu haben...
Ja, aber das andere ist ein PDF und um zu vergleichen ...
Ich denke es lohnt sich generell sich mit dem Ansatz zu beschäftigen, ob sich das für den Selfserver auswirkt
Dafür wären Statistiken nicht schlecht, aber trotz allem Telegraphenmastschwenkens ...
weiß ich nicht, ist das unser Schwerpunkt oder eher die Theorie?
Das war, wenn ich mich recht entsinne, einer meiner verzweifelter Versuche OT zu bleiben ;-)
AFAIK, kannst du die Länge des BWTransformierten Intervalls einstellen, je länger umso besser die Kompression.
Hingegen nur ganze Postings oder Threads zu nehmen würde zwar die Kompression herabsetzen, dafür aber aussagefähige Treffer liefern.
Nun, das wäre schon wieder eine Einstellungssache. Praktikabel zwar, aber mir wiederstrebend.
Mmh ... Heisenberg in der Informationstheorie? ;-)
Natürlich! Ganz ohne Ironie!
Nein, durchaus mit. Das was da so merkwürdig aussieht ist schlichte Kosten-Nutzenrechnung also Ökonomie.
Die Ähnlichkeit ist aber in diesem Falle derart frappant, das ich mich einfach nicht beherrschen konnte, sorry.
Meines Wissens ist das Vokabular der Chinesen nicht überdurchschnittlich groß?
Hmmm ... Hörensagen ... kann jetzt keinen Beleg dafür finden, insbesondere, weil die Definition von Chinesisch wg der viele Einzelsprachen und Dialekte schwammig ist.
Da hast Du natürlich Recht.
Gut, dann gelte in diesem Falle als "Chinesisch" der Mandarin-Dialekt.
Hingegen beim Englischen ...
"English is noted for the vast size of its active vocabulary and its fluidity. English easily accepts technical terms into common usage and imports new words which often come into common usage" http://en.wikipedia.org/wiki/English_language#Vocabulary
Ich häte da doch gerne eine neutrale Instanz und nicht die Sprecher dieser Sprache selber ;-)
Immerhin trifft das mit dem Aufsaugen deutlich mehr auf die deutsche Sprache zu, als auf die englische.
Das sagt natürlich ein Sprecher dieser Sprache selber, klar ;-)
Die englische Orthographie ist auch nicht sonderlich unregelmäßig. Sie enstand aus zwei unterschiedlichen Stämmen, deshalb sieht das mitunter merkwürdig aus, ist aber recht logisch geblieben.
HA!
*swiff* (Geräusch eines blank ziehenden Kendoka)
Wer?
"English spelling is often considered to be one of the most difficult to learn of any language that uses an alphabet" http://en.wikipedia.org/wiki/English_language#Writing_system
Weil es aus zwei Sprachen besteht, ja. Macht aber rein gar nix.
Deutsch wird schon sehr phonetisch geschrieben, z.B. Spanisch ist in der Beziehung schon nahe am Optimum.
Ja, das ist mir auch schon aufgefallen, im Spanischem mache ich viel weniger Rechtschreibfehler.
http://forum.de.selfhtml.org/archiv/2004/8/t86714/#m516043
Ich glaube du sprichst aber hier eher von den Problemen der Rechtschreibung (Groß/Klein, getrennt/zusammen, ß/ss) die das Englische nicht hat, das macht sich aber IMHO bei einer Kompression kaum bemerkbar.
Nein, zumindest nicht direkt, sondern als ein Faktor von vielen. Einiges tut natürlich auch noch der Umstand dazu, das die Erforscher von Kompressionsmöglichkeiten Englisch als Muttersprache hatten.
Ob gewollt oder nicht: das hatte Einfluß.
Eher Nachteilig könnte die von dir erwähnten 10% längeren Texte sein, da IMHO im deutschen präziser/pedantischer gesprochen wird, wo dem Engländer der Kontext bereits zur Klärung aussreicht.
Die Wörter sind im Schnitt länger ;-)
Nein, klar, der deutsche möchte es auch sprachlich immer etwas korrrrrekter haben.
Und wenn sich damals nicht mal zwei Leute verkracht hätten würden wir heute französisch quasseln ;-)
Hä? Meinst du jetzt Karl den Kahlen und Anverwandte? Oder Friedrich II und Voltaire?
Naja, bei Voltaire wars' schon lange zu spät >;->
Gewagte Thesen! :)
Nein, reine Deduktion. Wenn eine Entscheidung zwischen zwei Dinge _nicht_ getroffen wurde haben sich mindestens zwei Personen verkracht. War schon immer so und wird auch immer so bleiben ;-)
so short
Christoph Zurnieden
Hi
Ja, aber das andere ist ein PDF und um zu vergleichen ...
Ach falls du auf die schlechte Qualität anspielst, da hatte jemand vom Zusammenspiel von TeX, PS und PDF beim Konvertieren keine Ahnung! >:)
Hingegen nur ganze Postings oder Threads zu nehmen würde zwar die Kompression herabsetzen, dafür aber aussagefähige Treffer liefern.
Nun, das wäre schon wieder eine Einstellungssache. Praktikabel zwar, aber mir wiederstrebend.
Bezweifle dass die Kompression so stark leiden würde, die wär ja auch nur ein Seiteneffekt (der die Suchgeschwindigkeit im Übrigen auch senken würde)
Die englische Orthographie ist auch nicht sonderlich unregelmäßig. Sie enstand aus zwei unterschiedlichen Stämmen, deshalb sieht das mitunter merkwürdig aus, ist aber recht logisch geblieben.
Wenns nur das wäre, ein befreundeter Germanist hat mir letztens erklärt es liegt an einer Serie von missglückten Rechtschreibreformen, wo immer wieder eine etymologische Rechtschreibung gefordert wurde, so dass die Herkunft erkennbar ist. Night=Nacht usw. Auch kannst du ohne großen Widerstand viele europäische Fremdwörter einführen, solange sie sich gewählt genug anhört.
IMHO haben auf der Insel haben viel zu lange Snobs das sagen gehabt, die sich sprachlich von der Arbeiterklasse absetzen wollten.
Weil es aus zwei Sprachen besteht, ja. Macht aber rein gar nix.
Dann wärs ja die Summe 2er Systeme! Ist es aber nicht! Französisch ist weit phonetischer als Englisch, und bei einem großen Teil der germanischstämmigen Wörter kannst du nach simplen hören auch nicht sagen wie sie geschrieben werden.
Bye
rolf
Hi,
Ja, aber das andere ist ein PDF und um zu vergleichen ...
Ach falls du auf die schlechte Qualität anspielst, da hatte jemand vom Zusammenspiel von TeX, PS und PDF beim Konvertieren keine Ahnung! >:)
Nein, die "Seekrankheit" meine ich nicht ;-)
Aber es ist zu reparieren, nur fehlen mir halt die Fonts zur Anzeige, das ist alles.
Nun, das wäre schon wieder eine Einstellungssache. Praktikabel zwar, aber mir wiederstrebend.
Bezweifle dass die Kompression so stark leiden würde, die wär ja auch nur ein Seiteneffekt (der die Suchgeschwindigkeit im Übrigen auch senken würde)
Mir geht es um da einstellen an und für sich. Meist ist so etwas ein deutliches Zeichen, das etwas nicht wirklich optimal läuft. Anders natürlich, wenn Du die Einstellung im Vorraus berechnen kannst, ein, wenn auch nur theoretisches Optimum a priori zu bestimmen vermagst. Versuch&Irrtum zählt aber nicht dazu.
Die englische Orthographie ist auch nicht sonderlich unregelmäßig. Sie enstand aus zwei unterschiedlichen Stämmen, deshalb sieht das mitunter merkwürdig aus, ist aber recht logisch geblieben.
Wenns nur das wäre, ein befreundeter Germanist hat mir letztens erklärt es liegt an einer Serie von missglückten Rechtschreibreformen, wo immer wieder eine etymologische Rechtschreibung gefordert wurde, so dass die Herkunft erkennbar ist. Night=Nacht usw. Auch kannst du ohne großen Widerstand viele europäische Fremdwörter einführen, solange sie sich gewählt genug anhört.
Jetzt mal ganz böse gefragt: was bitte unterscheidet das vom Deutschen?
IMHO haben auf der Insel haben viel zu lange Snobs das sagen gehabt, die sich sprachlich von der Arbeiterklasse absetzen wollten.
Weil es aus zwei Sprachen besteht, ja. Macht aber rein gar nix.
Dann wärs ja die Summe 2er Systeme!
Na, mehr so XOR glaube ich.
Ist es aber nicht! Französisch ist weit phonetischer als Englisch, und bei einem großen Teil der germanischstämmigen Wörter kannst du nach simplen hören auch nicht sagen wie sie geschrieben werden.
Mmh ... geht das jetzt gegen oder für mich? ;-)
so short
Christoph Zurnieden
Hi
Wenns nur das wäre, ein befreundeter Germanist hat mir letztens erklärt es liegt an einer Serie von missglückten Rechtschreibreformen, wo immer wieder eine etymologische Rechtschreibung gefordert wurde, so dass die Herkunft erkennbar ist. Night=Nacht usw. Auch kannst du ohne großen Widerstand viele europäische Fremdwörter einführen, solange sie sich gewählt genug anhört.
Jetzt mal ganz böse gefragt: was bitte unterscheidet das vom Deutschen?
Englisch ist viel schlimmer!
http://en.wikipedia.org/wiki/English_orthography
Tschau
rolf
Hi,
Meint der doch glatt, ich wär' Grundschullehrer!
Seh' ich etwa so aus?Ne eher wie ein Körperpfleger! ;)
Meines Wissens gibt es von mir kein Photo im Netz, wer also hat Dir eines geschickt?
"A Bloom filter with 1% error and an optimal value of m, on the other hand, requires only about 9.6 bits per element" http://en.wikipedia.org/wiki/Bloom_filter#Space_and_time_advantages
Ich sag mal mit durchschnittlich 9.6 Bits kodiere ich die ganze Postingliste mit 0% Fehler. (diesmal bitte keine Bierkiste :)
1% ist aber recht viel, ein Promille ist da schon realistischer.
nee, Eigentoor, es ist sogar schlimmer, sofern dein Bloomfiltercaculator was taugt:
?
Achos, nein, ich meinte den Bedarf. 1% Fehlerquote wäre für den Cachingzweck einfach zuviel. Da es hier diskret zugeht, wären bei 400 Elementen und 1% Fehlerquote im Schnitt vier Stück falsch, bei 0,1% weniger als eines.
Aber ich befürchte ein Mathematiker läßt sich von meinen Milchmädchenrechnungen nicht verführen ;-)
Kostet aber natürlich auch nicht viel mehr pro Element, das ist wohl wahr. (0% ist sehr schwierig, da müßten nicht nur alle Hashfunktion minimal perfekt sein, sondern auch alle Permutationen.)
für 0% kann man keine Bloomfilter nehmen weil die grundsätzlich verlustbehaftet sind, selbst wenns im Nanobereich läge.
Ja, es ist eine Definitionsfrage, ob der Bloomfilter bei Fehlerfreiheit gar kein Bloomfilter mehr ist.
Aber wie gesagt: 0% gibt's hier nur mit minimal perfektem Hash. Und dann kannst Du Dir die Mühe mit dem Bloomfilter eh sparen und gleich eine normale Hastabelle nehmen und als fertiges Javascript-Array mitgeben.
Mmh ...
Auch keine schlechte Idee.Das war ja auch jetzt meine Idee ... naja macht nix.
Deswegen habe ich sie auch im Laufe meines "Nachdenkens" verworfen.
Nein, natürlich nicht deswegen ;-)
Steck deinen 400er-Cache in nen normalen JS-Hash ohne propietäre Hashfkt, das reicht doch dicke!
Er wäre aber immer noch um ein vielfaches "dicker" udn heutzutage liegen die höchsten Kosten nunmal bei der Übertragung. Bei SelfHTML umso mehr, als das die gesponort werden, wenn es also zuviel wird ist es möglich, das dem Sponsor es auch zuviel wird und er sich für die Zusammenarbeit bedankt und das Sponsoring einstellt.
Bei der Kostenminimierung den Transfer auszuschließen wäre demnach nicht gar so günstig.
Aber das ist hier auch nicht so schlimm, denn auf Grund der Statik des Arrays würde dieses Javascript gecached werden können.
und zippen kann wg der Entropie auch nix helfen.
Nein, tut mir leid, _so_ leicht führst Du mich nicht auf's Glatteis, ich hab' schon bemerkt, das Du hier die Informationsbits _netto_ zugrunde gelegt hast ;-)
hmm, ne Brutto,
400 (einträge) *10 Bytes /5-10 (gzip)=800-400 Bytes
Die Informationsbits sind die 9,6 Bit, das ist ein Nettobetrag, nach Abzug aller Redundanzen. Keine Redundanzen -> keine Kompression.
Das Gebiet "Suche" ist derart gut bekannt, das es für weiter signifikante Fortschritte der hellsten Köpfe bedarf. Deren Auswahl unter den Bewerbern soll _extrem_ scharf sein, einige berichteten von über 20 Interviews und wurden dann doch nicht genommen. Einzige Alternative ist also massiver Hardwareeinsatz.
ui dann will ich hier öffentlich nicht mehr Tricks verraten ;)
Ich würde das immer öffentlich machen, deswegen könnte ich, abgesehen von meiner Unfähigkeit, nie da anfangen.
Im ernst die Leute dürften dann in dem Bereich promoviert haben.
Nein, die wollen Leute, die es wirklich können >;->
BTW: Würde google anbieten suchergebnisse nach Anchors zu gliedern, bräuchten wir hier keine eigene Suchmaschine...
Wenn man denen das bezahlt machen die das sicherlich gerne.
Phh, wer will den Usern verbieten google zu nutzen?
Niemand, aber Google bietet ja keine Gliederung nach Anchors na, wie Du bereits sagtest (auch wenn ich ehrlicherweise keine Ahnung habe, was Du darunter genau verstehst).
Bei Ausfall der Archivsuche mußt und kannst Du auch Google gut benutzen. Wenn ich etwas im Archiv suche tue ich das auch stest als erstes, damit belaste ich den Selfserver schonmal ein Stückchen weniger; nicht nur bei der Rechenarbeit sondern vor allem auch beim Transfer.
PS: Wird einsam hier unten,
Nein, das sieht nur so aus.
meinst du es liest noch jmd mit oder sollen wir leiber aufs mailen ausweichen?
Normalerweise ist hier alleine schon die Frage verpönt, aber da wir uns so langsam beginnen im Kreise zu drehen, alles recht theoretisch wird und es dadurch zu Darstellungsproblemen kommt (nunmal ehrlich: längere und/oder komplexere Formeln in ASCII sind doch eine Quälerei, oder?) und sich bis jetzt keiner beschwert hat ...
so short
Christoph Zurnieden
Hi,
Ne eher wie ein Körperpfleger! ;)
Meines Wissens gibt es von mir kein Photo im Netz, wer also hat Dir eines geschickt?
Habs gerochen! (so gepflegtes Odeur, wow ;)
Ja, es ist eine Definitionsfrage, ob der Bloomfilter bei Fehlerfreiheit gar kein Bloomfilter mehr ist.
Kann ein Bloomfilter fehlerfrei sein???
IMHO nein, da die Bits der Hashfunktionen verodert werden und so harte Informationen zugunsten der Kompression verloren gehen. Natürlich kann man die Wahrscheinlichkeit auf 0.0000000000000000000000000000001 treiben, und damit quasi keinen Fehler habe. Quasi ist aber nicht absolut, abgesehen vom exorbitanten Speicherbedarf.
Steck deinen 400er-Cache in nen normalen JS-Hash ohne propietäre Hashfkt, das reicht doch dicke!
Er wäre aber immer noch um ein vielfaches "dicker"
Nö wie bereits vorgerechnet, nicht. Denk auch daran das
der Code Platz braucht!
udn heutzutage liegen die höchsten Kosten nunmal bei der Übertragung.
Dann solltest du doch ganz auf JS-Cache-Checking verzichten und es Serverseitig machen, oder?
400 (einträge) *10 Bytes /5-10 (gzip)=800-400 Bytes
Die Informationsbits sind die 9,6 Bit, das ist ein Nettobetrag, nach Abzug aller Redundanzen. Keine Redundanzen -> keine Kompression.
Ich habe hier die Größe eines durchschnittlichen gzipten JS-Hashes mit 400 Einträgen aus dem Cache abgeschätzt, versuch mal mit Bloom dass zu unterbieten.
Nein, die wollen Leute, die es wirklich können >;->
Naja, den riesen Ansturm den google hat, liegt auch an der Tatsache das Erfolg sexy ist. Ob ich in dem Umfeld arbeiten möchte, mit lauter übermotivierten Leuts die zu den Gewinnern gehören wollen?
Phh, wer will den Usern verbieten google zu nutzen?
Niemand, aber Google bietet ja keine Gliederung nach Anchors na, wie Du bereits sagtest (auch wenn ich ehrlicherweise keine Ahnung habe, was Du darunter genau verstehst).
Im Archiv sind ganze Threads wo die einzelnen Postings durch Anchors zergliedert sind.
Googletman also z.B. nach Christian und Kruse und site:selfhtml.org bekommt man auch Threads wo ein Christian Müller auf einen Herrmann Kruse antwortet (Frei erfunden, Ähnlichkeiten zu lebenden Personen sind natürlich ...;)
Bei Ausfall der Archivsuche mußt und kannst Du auch Google gut benutzen.
Naja mit obiger Einschränkung.
Wenn ich etwas im Archiv suche tue ich das auch stets als erstes, damit belaste ich den Selfserver schonmal ein Stückchen weniger; nicht nur bei der Rechenarbeit sondern vor allem auch beim Transfer.
Das schreit doch nach einer JS-Lösung, du nimmst einen für die Suche reservierten Browser mit ausreichen Cache und du belastet den Server gar nicht mehr ;)
(naja man müßte dann die Hashes nach Zeitphasen organisieren, damit der Großteil statisch bliebe und ein expire=never bekäme)
Normalerweise ist hier alleine schon die Frage verpönt,
Ach sah ich hier schon öfter, zu dem könnte ich für uns noch ein Forum mit Texsupport anbieten :)
(nunmal ehrlich: längere und/oder komplexere Formeln in ASCII sind doch eine Quälerei, oder?)
ja insbesondere weil ich nicht gerne rechne,(bin in denr Beziehung ein echter Mathematiker) aber manchmal ist Prosa alleine halt zu fehlerbehaftet um Infos zu übermitteln.
und sich bis jetzt keiner beschwert hat ...
Es wiederholt sich tatsächlich viel.
Aber jetzt noch mal ein Schlußwort, mit ein bißchen Fantasie wo ich zukünftig der Schwerpunkt bei der Self-Suchmaschine legen würde:
OK, eine Zusatzprogrammierung von Hashes für weitere Performancesteigerung als mit der DB-Lösung rechnet sich bei der heutigen Auslastung kaum. D'accord! Aber ...
1. Was wäre aber wenn viel mehr "automatisierte" Abfragen realisieren wollte?
z.B.
a) bei jedem neuen Posting werden User auf vergleichbare Posts im Archiv hingewiesen.
b) Oder beim Blättern in Selfhtml-Tutorial werden automatisch alle Postings gelistet die sich auf einen bestimmten Paragraphen beziehen?
2. Die Datenstruktur sollte auch nützliche Zusatzfeatures unterstützen helfen:
z.B.
a) Wort- Ähnlichkeitssuche wo auch Typos mit erfasst werden. (einfache Permutationen, ausgelassene Buchstaben)
b) Posting- Ähnlichkeitssuche wo thematisch verwandte Posts anhand gemeinsamer Wörter gesucht werden.
[IMHO c't 19/2003 Textklassifizierung: Sortieren per Software, S.192 ]
c) Google Ranking wo oft mit <> zitierte Postings
weiter oben gelistet werden.
Bye
rolf
Hi,
hier stand 'was von Schlußwort, deshalb und vor allem zwecks Einhaltung der Gesetze:
Ne eher wie ein Körperpfleger! ;)
Meines Wissens gibt es von mir kein Photo im Netz, wer also hat Dir eines geschickt?
Habs gerochen! (so gepflegtes Odeur, wow ;)
Und dich dachte immer Bergaufseife riecht nach gar nix?
Kann ein Bloomfilter fehlerfrei sein???
IMHO nein, da die Bits der Hashfunktionen verodert werden und so harte Informationen zugunsten der Kompression verloren gehen. Natürlich kann man die Wahrscheinlichkeit auf 0.0000000000000000000000000000001 treiben, und damit quasi keinen Fehler habe. Quasi ist aber nicht absolut, abgesehen vom exorbitanten Speicherbedarf.
Wenn man die Kompression wegläßt und mit minimal perfekten Hashfunktionen udn ausreichnder Filterlänge dafür sorgt, das es kein Doubletten gibt, kann ien Bloomfliter fehlerfrei arbeiten.
Was das dann allerdings für einen Sinn machte, bliebe dahingestellt.
Steck deinen 400er-Cache in nen normalen JS-Hash ohne propietäre Hashfkt, das reicht doch dicke!
Er wäre aber immer noch um ein vielfaches "dicker"
Nö wie bereits vorgerechnet, nicht. Denk auch daran das
der Code Platz braucht!
Was für ein Code? Den MD5-Code? Ja, da kommt einiges zusammen. Das wäre dann aber im Gegensatz zu den regelmäßig aufgefrischten Daten ständig gecached. Falls sich der Browser an die Vorgaben des Expire hält natürlich und nicht zwischendurch geleert wird. Dürfte aber deutlich länger halten, als nur ein paar Tage.
udn heutzutage liegen die höchsten Kosten nunmal bei der Übertragung.
Dann solltest du doch ganz auf JS-Cache-Checking verzichten und es Serverseitig machen, oder?
Rein theoretisch ja, da hast Du natürlich Recht. Die ganze Spielerei darf statistisch nicht weiter auffallen, muß unterhalb der Rauschgrenze bleiben. Das kann man natürlich nicht festlegen, ohne die Statistik zu kennen und ist deshalb natürlich nur rein theoretisch zu betrachten.
400 (einträge) *10 Bytes /5-10 (gzip)=800-400 Bytes
Die Informationsbits sind die 9,6 Bit, das ist ein Nettobetrag, nach Abzug aller Redundanzen. Keine Redundanzen -> keine Kompression.
»»
Ich habe hier die Größe eines durchschnittlichen gzipten JS-Hashes mit 400 Einträgen aus dem Cache abgeschätzt, versuch mal mit Bloom dass zu unterbieten.
Beim Hash kämen noch ein paar Bytes für die Javascriptsyntax hinzu, aber das macht nicht viel aus, sind insgesammt nach dem Zippen etwa 1.000 Bytes. Plusminus. Der Bloomfilter wäre in etwa gleich groß, dazu kämen dann die zeitlichen Anteile an den Hashfunktionen. Die kämen dann abe auch bei beiden hinzu. Menge an zu übertragenden Daten wäre also in etwa die Gleiche. Nur wäre ein einfaches Array (gar nicht erst ein Hash o.ä. sondern ein simples assoziatives Array) eben genau das: einfach.
Oder hast Du gar keine Hashtabelle sondern genau so ein Array gemeint?
Nein, die wollen Leute, die es wirklich können >;->
Naja, den riesen Ansturm den google hat, liegt auch an der Tatsache das Erfolg sexy ist. Ob ich in dem Umfeld arbeiten möchte, mit lauter übermotivierten Leuts die zu den Gewinnern gehören wollen?
Ja, soziale Kompetenz gehört, wie ich vernahm, auch zu den höher geschätzten Fertigkeiten. Ein gutes Klima bringt eben auch einiges an Produktivität.
Im Archiv sind ganze Threads wo die einzelnen Postings durch Anchors zergliedert sind.
Ah, hätte ich also mal ganz einfach denken sollen ;-)
Googletman also z.B. nach Christian und Kruse und site:selfhtml.org bekommt man auch Threads wo ein Christian Müller auf einen Herrmann Kruse antwortet (Frei erfunden, Ähnlichkeiten zu lebenden Personen sind natürlich ...;)
Nimst Du Anführungsstriche geht's.
Aber ich weiß, was Du meinst, ja.
Die Threads werden allerdings in einer Einzeldatei angezeigt, da kann man die Browsersuche nutzen. Ist ja nicht jeder Thread so lang wie der hier z.B.
Wenn ich etwas im Archiv suche tue ich das auch stets als erstes, damit belaste ich den Selfserver schonmal ein Stückchen weniger; nicht nur bei der Rechenarbeit sondern vor allem auch beim Transfer.
Das schreit doch nach einer JS-Lösung, du nimmst einen für die Suche reservierten Browser mit ausreichen Cache und du belastet den Server gar nicht mehr ;)
Ja, ich weiß auch nicht mehr genau, warum man die Archive nicht mehr so einfach und paketiert runterladen kann (Datenschutz glaube ich, oder doch Transferkosten?). Das wäre dann natürlich die serverschonendste Variante, wenn da nicht die täglichen Updates wären. Die müßte dann jeder bekommen, der sein Archiv up-to-date halten wollte. Ich befürchte da käme einiges zusammen.
Normalerweise ist hier alleine schon die Frage verpönt,
Ach sah ich hier schon öfter,
Normalerweise macht man das aber stillschweigend, also direkt über Mail und läßt den Thread leise versterben.
zu dem könnte ich für uns noch ein Forum mit Texsupport anbieten :)
Gut, so einen kleinen Sverer, der auf einem Socket lauscht, mit Latex/AMS-TeX formatierte Snippets annimmt und PNGs zurückgibt hatte ich auch mal im Auge, aber TeX ist leider recht teuer in der Ausführung.
(nunmal ehrlich: längere und/oder komplexere Formeln in ASCII sind doch eine Quälerei, oder?)
ja insbesondere weil ich nicht gerne rechne,(bin in denr Beziehung ein echter Mathematiker) aber manchmal ist Prosa alleine halt zu fehlerbehaftet um Infos zu übermitteln.
Ja, genau. Ich versuch's ja auch immer ohne, aber wie hätte ich z.B. in dürren Worten die Funktionsfähigkeit der Entropieverbesserung bei Pseudozufallsgeneratoren durch regelmäßigen, durch XOR verknüpftem Seed mit echtem Zufall beweist?
(Ja, ist kein strenger Beweis, mir schon klar, aber _dazu_ fehlt mir dann nicht nur die Geduld sondern auch das Vermögen.)
- Was wäre aber wenn viel mehr "automatisierte" Abfragen realisieren wollte?
Auha, jetzt geht's auf die Luxuschiene, jetzt wird der Champagner (Millesime!) kaltgestellt und weißer Trüffel über die Butternudeln gehobelt ;-)
z.B.
a) bei jedem neuen Posting werden User auf vergleichbare Posts im Archiv hingewiesen.
Kategorisierung, gut das können Spamfilter erledigen.
b) Oder beim Blättern in Selfhtml-Tutorial werden automatisch alle Postings gelistet die sich auf einen bestimmten Paragraphen beziehen?
Fällt bei Implementation von a) automatisch mit ab.
Und jetzt die Doppelmagnum vom 45er Chateau Petrus dekantieren auf das er atmne kann, denn es kömmt der Fleischgang:
- Die Datenstruktur sollte auch nützliche Zusatzfeatures unterstützen helfen:
z.B.
a) Wort- Ähnlichkeitssuche wo auch Typos mit erfasst werden. (einfache Permutationen, ausgelassene Buchstaben)
Ja, das wäre nicht verkehrt, wohl wahr.
b) Posting- Ähnlichkeitssuche wo thematisch verwandte Posts anhand gemeinsamer Wörter gesucht werden.
Fällt das nicht auch unter 1a)?
[IMHO c't 19/2003 Textklassifizierung: Sortieren per Software, S.192 ]
Naja, da würde ich mich schon auf profundere Quellen stützen wollen ;-)
c) Google Ranking wo oft mit <> zitierte Postings
weiter oben gelistet werden.
Das ist so ganz nackt nicht praktikabel, leider, das verführt zu Mißbrauch oder macht es dadurch zunichte, indem einfach jeder jeden verlinkt (Akademie: "Zitierst Du mich zitier ich dich.")
so short
Christoph Zurnieden
Hi,
Wenn man die Kompression wegläßt und mit minimal perfekten Hashfunktionen udn ausreichnder Filterlänge dafür sorgt, das es kein Doubletten gibt, kann ien Bloomfliter fehlerfrei arbeiten.
Das ist kein Jim Bloom! ;) Du hättest nur noch einen perfekten Hash (bei mehreren müsstest du OR-verknüpfen =Verlust) der pro Hashwert bijektiv auf ein Bit abbildet. Sowas nen ich einfach einen exotischen perfekten Hash.
Nur wäre ein einfaches Array (gar nicht erst ein Hash o.ä. sondern ein simples assoziatives Array) eben genau das: einfach.
Einfach simple oder einfach perfekt für die Aufgabenstellung?
Oder hast Du gar keine Hashtabelle sondern genau so ein Array gemeint?
ich meinte ein Hashes als JS Assoziative Arrays umgesetzt http://de.selfhtml.org/javascript/objekte/array.htm#assoziative_arrays
wobei man nicht jedesmal sowas wie
cache["HTML"]=1 eintragen müßte, das geht mit Literalen bestimmt noch platzsparender.
Aber ich weiß, was Du meinst, ja.
Die Threads werden allerdings in einer Einzeldatei angezeigt, da kann man die Browsersuche nutzen. Ist ja nicht jeder Thread so lang wie der hier z.B.
Mit Browsersuche findest du kaum, ob in _einem_ Posting
3 Stichwörter _überhaupt_ auftauchen!?!
Normalerweise macht man das aber stillschweigend, also direkt über Mail und läßt den Thread leise versterben.
Dann hätte aber kein stiller Mit(l)esser ne Chance zu protestiern.
Gut, so einen kleinen Sverer, der auf einem Socket lauscht, mit Latex/AMS-TeX formatierte Snippets annimmt und PNGs zurückgibt hatte ich auch mal im Auge, aber TeX ist leider recht teuer in der Ausführung.
Bei mir ohne PNGs :), möchtest du PNGs würd ich LAtex2html oder t4ht empfehlen...
Ja, genau. Ich versuch's ja auch immer ohne, aber wie hätte ich z.B. in dürren Worten die Funktionsfähigkeit der Entropieverbesserung bei Pseudozufallsgeneratoren durch regelmäßigen, durch XOR verknüpftem Seed mit echtem Zufall beweist?
schluck, ok ich schaus mir also doch mal an ... ;)
- Was wäre aber wenn viel mehr "automatisierte" Abfragen realisieren wollte?
Auha, jetzt geht's auf die Luxuschiene, jetzt wird der Champagner (Millesime!) kaltgestellt und weißer Trüffel über die Butternudeln gehobelt ;-)
für mich kein Alk bitte!
z.B.
a) bei jedem neuen Posting werden User auf vergleichbare Posts im Archiv hingewiesen.Kategorisierung, gut das können Spamfilter erledigen.
kommt auf den Spamfilter an, aber ja sowas meinte ich hier.
b) Oder beim Blättern in Selfhtml-Tutorial werden automatisch alle Postings gelistet die sich auf einen bestimmten Paragraphen beziehen?
Fällt bei Implementation von a) automatisch mit ab.
mit Beziehen meinte ich es gibt einen Link zum betreffenden Paragraphen in Selfhtml rein, wie weiter oben in diesem Posting.
b) Posting- Ähnlichkeitssuche wo thematisch verwandte Posts anhand gemeinsamer Wörter gesucht werden.
Fällt das nicht auch unter 1a)?
schon ein komplizierterer Ansatz...
[IMHO c't 19/2003 Textklassifizierung: Sortieren per Software, S.192 ]
Naja, da würde ich mich schon auf profundere Quellen stützen wollen ;-)
Warum, das ist ein Übersichtsartikel der auf profunde Quellen verweist, und mit Grafiken hilft.
c) Google Ranking wo oft mit <> zitierte Postings
weiter oben gelistet werden.Das ist so ganz nackt nicht praktikabel, leider, das verführt zu Mißbrauch oder macht es dadurch zunichte, indem einfach jeder jeden verlinkt (Akademie: "Zitierst Du mich zitier ich dich.")
Hmm, aber, der Aufwand für Googlespaming im Forum steht nicht in einem vernünftigen Verhältnis zum Benefit!
Bei Google gewinnt man Kunden, im Forum hingegen ... Anerkennung??? Wer hätte also etwas davon?
Außerdem könnten die Moderatoren offensichtlich unnötiges Verlinken unterbinden, (sie müssen sowieso jeden Link folgen)
aber ich dreh mich im Kreis http://forum.de.selfhtml.org/archiv/2004/11/t94960/#m577598
Tschau
rolf
Hi,
Wenn man die Kompression wegläßt und mit minimal perfekten Hashfunktionen udn ausreichnder Filterlänge dafür sorgt, das es kein Doubletten gibt, kann ien Bloomfliter fehlerfrei arbeiten.
Mein lieber Mann, das wird ja immer schlimmer mit mir! Ich schwöre aber Stein und Bein stocknüchtern gewesen zu sein!
Vielleicht lag's ja genau daran? ;-)
Das ist kein Jim Bloom! ;)
Burton Bloom ist sein Name. Wie in: "Upon leaving the Burton, Bloom begins pondering the merits of vegetarianism" [James Joyce, "Ulysses"]
Du hättest nur noch einen perfekten Hash (bei mehreren müsstest du OR-verknüpfen =Verlust) der pro Hashwert bijektiv auf ein Bit abbildet. Sowas nen ich einfach einen exotischen perfekten Hash.
Jupp.
Aber nicht unmöglich! ;-)
Nur wäre ein einfaches Array (gar nicht erst ein Hash o.ä. sondern ein simples assoziatives Array) eben genau das: einfach.
Einfach simple oder einfach perfekt für die Aufgabenstellung?
Zumindest "simpel". "perfekt" würde bedeuten, das es nichts besseres gäbe, das würde ich nicht ohne genauerer Überprüfung zugeben wollen.
Oder hast Du gar keine Hashtabelle sondern genau so ein Array gemeint?
ich meinte ein Hashes als JS Assoziative Arrays umgesetzt http://de.selfhtml.org/javascript/objekte/array.htm#assoziative_arrays
wobei man nicht jedesmal sowas wie
cache["HTML"]=1 eintragen müßte, das geht mit Literalen bestimmt noch platzsparender.
Ein einfaches "ja" hätte mir auch schon gereicht, so ist das nicht ;-)
Aber ich weiß, was Du meinst, ja.
Die Threads werden allerdings in einer Einzeldatei angezeigt, da kann man die Browsersuche nutzen. Ist ja nicht jeder Thread so lang wie der hier z.B.Mit Browsersuche findest du kaum, ob in _einem_ Posting
3 Stichwörter _überhaupt_ auftauchen!?!
Ja, automatisch geht das in den mir bekannten Browsern nicht. Aber wie gesagt: so lang sie die Threads nicht, das kann man auch von Hand machen.
Du meinst aber mit Sicherheit auch das Problem, das ein Wort im ganzem Thread gleichmäßig verteilt sei bzw wie oft es im Thread vorkommt. Letzteres ist besonders bei Phrasen wichtig. (wenn eine Phrase oft vorkommt bedeutet das meist, das sie oft zitiert wurde, das Thema also damit eng zu tun hatte)
Da die Threads aber selten sehr lang sind, kann man das händisch prüfen. Gut: das Problem, das dadurch Transferkosten aufschlagen bekommt damit ein paar Zinsen drauf.
Normalerweise macht man das aber stillschweigend, also direkt über Mail und läßt den Thread leise versterben.
Dann hätte aber kein stiller Mit(l)esser ne Chance zu protestiern.
Es steht hier jedem frei eine Thread aufzumachen. Es wird auch nichts gesagt (ein paar sind immer dabei, die sich aufregen, aber die kann man auch getrost ignorieren) ein Thema neu aufzugreifen, wenn der Thread im Nirvana des Archivs verschwunden ist. Ein wenig Anstandsabstand zeitlicher Art ist jedoch empfehlenswert.
Bei mir ohne PNGs :), möchtest du PNGs würd ich LAtex2html oder t4ht empfehlen...
Nein, das Bilderzeugen ist noch das billigste, glaub's mir ;-)
Außerdem gäbe es Probleme mit der Prozeßanzahl, mit tmp-space usw. Man müßte auf PDF umschwenken, aber das ist dann wieder nicht portabel. Für MathML, die optimale Lösung, gilt natürlich das Gleiche: außer dem Mozilla kann das eigentlich keiner richtig.
Ja, genau. Ich versuch's ja auch immer ohne, aber wie hätte ich z.B. in dürren Worten die Funktionsfähigkeit der Entropieverbesserung bei Pseudozufallsgeneratoren durch regelmäßigen, durch XOR verknüpftem Seed mit echtem Zufall beweist?
schluck, ok ich schaus mir also doch mal an ... ;)
Nein, deswegen nicht (obwohl, wäre nett, dann weiß ich wenigstens, ob da ein Fehler drin ist ;-), nur wegen der Kürze einer Formel im Gegensatz zur Beschreibung.
Auha, jetzt geht's auf die Luxuschiene, jetzt wird der Champagner (Millesime!) kaltgestellt und weißer Trüffel über die Butternudeln gehobelt ;-)
für mich kein Alk bitte!
Macht nix, ist für mich mehr da. Oder möchtest Du im Austausch etwa gar eine doppelte Portion der Nudeln? ;-)
z.B.
a) bei jedem neuen Posting werden User auf vergleichbare Posts im Archiv hingewiesen.
Kategorisierung, gut das können Spamfilter erledigen.kommt auf den Spamfilter an, aber ja sowas meinte ich hier.
Spamfilter sind ganz gut für anonyme Kategorisierung geeignet. "Anonym" deshalb, weil die Kategorie keinen Namen bekommt, sondern nur eine Beziehung darstellt, rein abstrakter Natur ist.
Je mehr es von diesen Kategorien gibt - bei gleichzeitiger Statik der Datenmenge - desto "dünner" werden natürlich die Argumente der Zuweisung. Irgendwann landet sowas unterhalb der Rauschgrenze. Leider läßt sich aber nicht genau sagen wann.
mit Beziehen meinte ich es gibt einen Link zum betreffenden Paragraphen in Selfhtml rein, wie weiter oben in diesem Posting.
Ja, bleibt das Gleiche. Könnte aber bei Automatik schon recht dünn werden. Dafür wäre ein händisch erstelltes Best-Of wohl besser. Aber da kommt auch sofort die alte Frage: wer macht das?
b) Posting- Ähnlichkeitssuche wo thematisch verwandte Posts anhand gemeinsamer Wörter gesucht werden.
Fällt das nicht auch unter 1a)?
schon ein komplizierterer Ansatz...
Das wäre genau der Ansatz, den ich verfolgte. Nur nicht anhand gleicher Wörter sondern anhand von - nun: Ähnlichkeit eben.
Warum, das ist ein Übersichtsartikel der auf profunde Quellen verweist, und mit Grafiken hilft.
Ja, ich meinte auch eher Knuth et al.
Es gibt seitdem nichts wirklich Neues unter der Sonne. Es hat schon langen niemanden mehr gegeben, der dem "Was tun" etwas hinzugefügt hätte. Heute ist die Zeit des "Wie's tun" gekommen. Die Zeit der Ideen ist vorbei, die Zeit der Ingenieure ist angebrochen.
Ob's gut ist oder schlecht, wer weiß?
c) Google Ranking wo oft mit <> zitierte Postings
[...]
Hmm, aber, der Aufwand für Googlespaming im Forum steht nicht in einem vernünftigen Verhältnis zum Benefit!
Da wird die Spammer nicht jucken, glaub's mir *sigh*
Bei Google gewinnt man Kunden, im Forum hingegen ... Anerkennung??? Wer hätte also etwas davon?
Ja, frage nur, Antworten wirst Du keine bekommen.
Da! Noch ein Seufzer: *sigh*
;-}
Außerdem könnten die Moderatoren offensichtlich unnötiges Verlinken unterbinden, (sie müssen sowieso jeden Link folgen)
Na, die sollten schon so wenig Arbeit wie möglich haben. Insbesondere wenn's um's Löschen geht ist das eine verdammt undankbare Aufgabe.
aber ich dreh mich im Kreis http://forum.de.selfhtml.org/archiv/2004/11/t94960/#m577598
Das ist lange her, das ist doch schon gar nicht mehr wahr ;-)
so short
Christoph Zurnieden
Hi,
Das ist kein Jim Bloom! ;)
Burton Bloom ist sein Name.
Das ist kein Burton Beam!
...Sowas nen ich einfach einen exotischen perfekten Hash.
Jupp.
Aber nicht unmöglich! ;-)
Kann man ne Armee mit einer Vespa transportieren, klar wenn die Armee aus einem Mann besteht der gleichzeitig General und Gerfreiter und alle dazwischen ist...
Oder hast Du gar keine Hashtabelle sondern genau so ein Array gemeint?
ich meinte ein Hashes als JS Assoziative Arrays umgesetzt http://de.selfhtml.org/javascript/objekte/array.htm#assoziative_arrays
wobei man nicht jedesmal sowas wie
cache["HTML"]=1 eintragen müßte, das geht mit Literalen bestimmt noch platzsparender.Ein einfaches "ja" hätte mir auch schon gereicht, so ist das nicht ;-)
Mir ist nicht klar was der Unterschied zwischen assoziativem Array und normalen JS-Hash bei dir ist.
Bei mir ohne PNGs :), möchtest du PNGs würd ich LAtex2html oder t4ht empfehlen...
Nein, das Bilderzeugen ist noch das billigste, glaub's mir ;-)
so oder so wird TeX aufgerufen, bei der Bilderzeugung läuft zusätzlich noch eine DVI->PS->PNG Konvertierung, die am teuersten ist, glaubs mir! ;)
Für MathML, die optimale Lösung, gilt natürlich das Gleiche: außer dem Mozilla kann das eigentlich keiner richtig.
warum setzt noch keiner Unicode mit Hilfe von DIVs?
Schau dir mal die Übungsblätter an http://www.mathematik.tu-darmstadt.de/Math-Net/Lehrveranstaltungen/Lehrmaterial/WS2004-2005/AnaII/elz/
Auha, jetzt geht's auf die Luxuschiene, jetzt wird der Champagner (Millesime!) kaltgestellt und weißer Trüffel über die Butternudeln gehobelt ;-)
für mich kein Alk bitte!
Macht nix, ist für mich mehr da. Oder möchtest Du im Austausch etwa gar eine doppelte Portion der Nudeln? ;-)
Och Erdinger Alkoholfrei wär OK!
mit Beziehen meinte ich es gibt einen Link zum betreffenden Paragraphen in Selfhtml rein, wie weiter oben in diesem Posting.
Ja, bleibt das Gleiche.
wieso??? Ich suche nach dem Link nichts sonst!
z.B wird Thread t14199 bisher 5 mal referenziert [http://suche.de.selfhtml.org/cgi-bin/such.pl?suchausdruck=t14199&lang=on&feld=text&index_1=on&index_2=on&index_3=on&index_4=on&index_5=on&index_6=on&index_7=on&index_8=on&index_9=on&index_10=on&index_11=on&index_12=on&hits=100]
Genauso kann ichs mit Paragraphen in Selfhtml machen.
Das wäre genau der Ansatz, den ich verfolgte. Nur nicht anhand gleicher Wörter sondern anhand von - nun: Ähnlichkeit eben.
ich empfehle dir den "unprofunden" Artikel in der ct für nen ersten Einstieg, posten geht schlecht.
Warum, das ist ein Übersichtsartikel der auf profunde Quellen verweist, und mit Grafiken hilft.
Ja, ich meinte auch eher Knuth et al.
Es gibt seitdem nichts wirklich Neues unter der Sonne.
Ach was BWT ist von 94 oder so! Und genial!
Hmm, aber, der Aufwand für Googlespaming im Forum steht nicht in einem vernünftigen Verhältnis zum Benefit!
Da wird die Spammer nicht jucken, glaub's mir *sigh*
Lass sie doch, der Aufwand ist lächerlich hoch um im Ranking nach ner bestimmten Suchanfrage vor dem optimalen Ergebnis zu landen.
Vielleicht verstehen wir auch unterschiedliches unter Googleranking?
Na, die sollten schon so wenig Arbeit wie möglich haben. Insbesondere wenn's um's Löschen geht ist das eine verdammt undankbare Aufgabe.
Logisch!
Tschau
rolf
Hi,
gepostet frühmorgens um halb Acht? Immer noch auf? "Schon wieder" wäre
für Dich als Student ja doch eher unwahrscheinlich, oder?Doch, ich bin heute mal frueh aufgestanden, um 07:00 -- um mich wieder an
die Zeiten waehrend der Vorlesungen zu gewoehnen :)
Und das soll ich glauben? Findest Du das nicht ein wenig viel verlangt?
Was ich mit genauere Hash-Funktion meinte war, die Hash-Funktion des
Hashes aus der ersten Ebene benutzen, aber das Ergebnis nicht abschneiden
sondern in einer hoeheren Genauigkeit zu benutzen. Da muss man dann aber
auch mit groesseren Tabellen leben. Muss man halt abwaegen.
Dazu mußt Du aber auch die normalerweise 32/64 Bit (oder was auch immer der Grundtyp der Architektur ist) langen Hashwerte komprimieren, da kannst Du für nur ein paar Zyklen mehr auch gleich eine komplette neue Hashfunktion drauf ansetzen, die ist dann auch deutlich unabhängiger zur Ersten.
Mmh...
Wenn der ursprüngliche Hashwert noch zur Hand ist und der wie üblich 32/64 Bit lang ist könnte man ihn mit der Adresse der angehangenen Hashtabelle (die Subhashtabelle) XORen. Diese angesprochene Adresse ist ja unabhängig vom Eingangswert, von dem der Hashwert gebildet wurde. Der Eingangswert muß damit nicht vollständig durchgeklappert werden, falls es sich wie hier um Strings variabler Länge handelt. Spart ein paar Zyklen im Gegensatz zum vollständigem Hash und braucht keine größeren Tabellen.
Aber jetzt fang ich ja selber schon mit Mikrooptimierung an.
so short
Christoph Zurnieden
Hi
Aeh, ja, das hat ja keiner bestritten. Aber ich brauche in jedem Loch 8
Byte statt 4 (wenn man von 4-Byte-Pointern ausgeht), wenn ich in einer
Zelle zwei Werte speichern muss (naemlich den neuen Hash zweiter Ordnung
und den alten Wert). Das macht bei einer Tabelle mit 2^16 = 65536
Elementen dann 256KB mehr. Packe ich jedoch auch das alte Element in die
Tabelle zweiter Ordnung, mit einer _anderen_ Hashfunktion oder einer
genaueren Hash-Funktion, dann kann ich mir das sparen.
Ihr habt Probleme ... das Verfahren soll Laufzeit _und_ Speichereffizient sein, da H per Definition ins RAM passt (soll heißen wird entsprechend klein gewählt, 2^16 war nur ne Hausnummer). Die Idee ist das H im RAM die teuren Zugriffe auf die K_i möglichst reduzieren hilft, mit so großen Zellen wie vertretbar. Man kann auch ganz auf H verzichten und immer auf die Platte zugreifen (s.u.)
Die Zelle i enthalten neben den Verweis aufs K_i-Hash auf der Platte tatsächlich noch einen Wert aus K_i, um Zugriffe auf die Platte zu minimieren und funktioniert somit quasi als Cache.
Das könnte z.B. der letzte abgefragte Wert aus K_i sein, oder der häufigste. Oder beides, das hängt von der günstigsten Cachingstrategie ab, die sich nur nach empirischen Untersuchungen des Nutzerverhaltens
spekulationsfrei angeben läßt.
Verzichte ich auf Laufzeitoptimierung, kann die Zelle auch nur die Referenz auf K_i enthalten.
Wähle ich die K_i alle gleich groß (k' Bits), kann ich auch ganz auf H (h' Bits) verzichten, wenn ich sie entsprechen auf der Platte als Tabelle mit p'=h'+k' Bits organisiere. Die resultierend Tabelle P ist dann effektiv ein Hash p' Bits und die zugehörige Fkt wäre p(w)=h(w)*2^q+k(w).
Algebraisch ist das ein sogenanntes "direktes Produkt" P = H x K.
Das h und k unabhängig sein müssen, kann man gut mit einer Analogie zu Vektorräumen motivieren. Mutipliziere ich diese, müssen die Basen auch unabhängig sein, damit die maximale Dimension erreicht wird. Sind die Basen identisch, dann ist die Dimension minimal.
Deswegen kann ich auch den umgekehrten Weg gehen und und von einer "zufälligen" Fkt p ausgehend, h und k generieren (sogenannte "direkte Zerlegung").
Wähle ich die K_i nicht immer gleich groß, spare ich zum einen Platz auf der Platte und zum anderen Reorganisationen der k-Hashes.
Algebraisch ist P dann ein "subdirektes Produkt", umgekehrt ließe
sich auch eine "subdirekte Zerlegung" einer einzigen großen Fkt p organisieren (das war mein Vorschlag, bei dem k_i mit maskierten Bits gewonnen wird)
Wozu nun der ganze Sermon:
Ich wollte zeigen das man die Ganzwortsuche sehr wohl in Hashes effektiv organsisieren kann, die auf Platte und RAM verteilt sind.
Ich denke das ist mir gelungen, PoC braucht es nicht weil logisch, meine einzige Unbekannte in diesem Spiel ist der Aufwand für geeignete Funktionen.
Sollte man es realisieren? Für die Selfsuche würde sich IMHO der Zeitgewinn zur DB nur messen aber nicht mehr wahrnehmen lassen, da alleine der HTTP/HTML Overhead die Antwortzeit dominieren wird.
mathematische Grüße
Rolf
Hi
Ah, jetzt verstehe ich: Du möchtest nicht nur das Problemkind, sondern alles in die zweite Tabelle packen?
Mein Gott jetzt hat er's!
Mein Gott jetzt hat er's!
Es grünt so grün wenn Spaniens Blüten blühen... lalalala!
Operettengrüße ;)
Rolf
Hi
Tja, das hatte ich befürchtet, das ist auch sehr schlecht vorstellbar. Also nochmal:
Stell Dir vor, Du hast eine Hashtabelle H mit 5 Löchern {a,b,c,d,e} und eine Funktion f(x), die alle Elemente einer Menge S gleichmäßig auf diese Löcher abbildet. Ist |S| größer als |H| dann kommt es zu Mehrfachbelegung, zu Kollisionen. Nun steht hinter jenen Löchern von H je eine weitere Hashtabelle H_i = {f,g,h,i,j}.
Zuerst wird jedes Loch in H gefüllt (wir setzen einmal eine optimale Verteilung der Hashwerte voraus), nach fünf Vorgängen erfolgt also die erste Kollision, sagen wir mal in a. Wir brauchen nun also eine Hashfunktion, die ein Element aus S in H_i packt. Was hindert uns nun daran, ebenfalls f(x) zu nehmen? Dadurch, das H voll ist, wird eine _neue_ Hastabelle genommen, wir fangen sozusagen bei 0 an. D.h.: wir können den alten Hashwert nehmen, der funktioniert für H_i genauso gut oder schlecht, wie für H. Vorausgesetzt natürlich, das |H| = |H_i|, aber das trifft in Deinem Beispiel ja zu.
Jetzt verstanden? Na, ich sehe noch zweifelnde Blicke ...
Bastel Dir einfach ein Beispiel, oder mal's Dir auf, das hilft mir auch mitunter.
Ich fürchte ich war immer noch nicht explizit genug! Du gehst davon aus das immer neue Tabellen fixer Größe aufgefüllt werden sobald eins "zu voll ist", sprich zuviele Kollisionen. Nein, stattdessen werden Tabellen aufgefüllt mit allen _jeweiligen_ Kollisionen.
Rein formal: Die Kollisionen an der Stelle x in H sind
W_x={w ∈ W| h(w)=x}
diese und nur diese werden dann in K_x auf der Platte eingespeißt, wäre k=h folgte aber
mit w ∈ W_x: k(w)=h(w)=x
Ist K "zu voll" (75%) wird keine neue Tabelle M angelegt, sondern K wird verdoppelt.
Aufmalen kann ichs dir jetzt leider schlecht...
Schnittmenge bilden ist _sehr_ teuer. Noch teurer fast, als ein grep durch's Archiv. Wenn das sein muß, ist die ganze vorherige Optimierung für die Katz.
(Da es sortierte Listen bekannter Länge sind, könnte man die Schnittmengenbildung evt(!) auf nlogn runterbringen, aber auch nur als Best Case. Durchschnitt wäre n^2 und Worst case n^3. Mmh... nein, Worst Case käme gar nicht vor, oder?)
Was ist hier n? Ist |L_i| die Mächtigkeit der i-ten Liste und
n= Σ |L_i|, dann ist doch wohl O(n)!?! Wenn die Mengen aufsteigend geordnet sind brauche ich jedes nur Element nur 1 mal anzufassen, oder verwechsle ich hier was ?
Ganz trivial: 2 geordnete Mengen, vergleiche die beiden kleinsten Elemente, sind sie identisch dann sind sie im Schnitt und man streicht beide ansonsten streicht man nur das kleinere. Das so lange bis eine Liste leer ist.
Wie macht es die DB?
Tschau
rolf
Hi,
Ich fürchte ich war immer noch nicht explizit genug! Du gehst davon aus das immer neue Tabellen fixer Größe aufgefüllt werden sobald eins "zu voll ist", sprich zuviele Kollisionen.
Nein, das hast Du doch korrigiert. Jedes Loch der ersten Hashtabelle hat eine zweite dahinter, diese hat dann hinter jedem Loch die üblichen linked lists.
Nein, stattdessen werden Tabellen aufgefüllt mit allen _jeweiligen_ Kollisionen.
Rein formal: Die Kollisionen an der Stelle x in H sind
W_x={w ∈ W| h(w)=x}
diese und nur diese werden dann in K_x auf der Platte eingespeißt, wäre k=h folgte aber
mit w ∈ W_x: k(w)=h(w)=x
Ja, genau, aber nicht für H, sondern für H_i, eine ganz andere Hashtabelle. Da ist das Loch beim erstem Mal noch leer.
(Da es sortierte Listen bekannter Länge sind, könnte man die Schnittmengenbildung evt(!) auf nlogn runterbringen, aber auch nur als Best Case. Durchschnitt wäre n^2 und Worst case n^3. Mmh... nein, Worst Case käme gar nicht vor, oder?)
Was ist hier n? Ist |L_i| die Mächtigkeit der i-ten Liste und
n= Σ |L_i|, dann ist doch wohl O(n)!?! Wenn die Mengen aufsteigend geordnet sind brauche ich jedes nur Element nur 1 mal anzufassen, oder verwechsle ich hier was ?
Wahrscheinlich die Schreibweise. Die O-Notation wird hin und wieder verkürzt (durch n geteilt) bzw ist das 'O' eigentlich zwei verschiedene Buchstaben, zwei verschiedene Angaben. Mach Dich einfach mal kundig über "O-Notation", dsa Wiki ist hier glaueb ich ausnahmsweise gut, bin ich jetzt aber zu faul, dsa zu kontrollieren.
Ganz trivial: 2 geordnete Mengen, vergleiche die beiden kleinsten Elemente, sind sie identisch dann sind sie im Schnitt und man streicht beide ansonsten streicht man nur das kleinere. Das so lange bis eine Liste leer ist.
Ja, genau das meinte ich und das bedeutet eine Komplexität von O(n*log(n)). Du mußt jeden einmal anfassen (n), weil Du aber nach dem Vergleich streichen kannst (bzw eine Suche in einer sortierten Liste bekannter Länge eh nur log(n) dauert), mußt Du nicht n-mal vergleichen, sondern nur log(n)-mal.
Worst case ist hier, das beide Mengen keine gemeinsamen Elemente haben, jedes Element mit jedem verglichen werden müßte: O(n^3). Ausgehend aber davon, das eine Suche in einer sortierten Liste bekannter Länge nur log(n) dauert, ist Worst Case hier "nur" O(n^2 * log(n)).
Habe ich das richtig erklärt Christian? Stimmt alles?
so short
Christoph Zurnieden
NACHTRAG: weil letzte Nacht der Server um 4:30 abgestüzt war, (deswegen gings sicherheitshalber schonmal als mail an christoph und christian raus.)
" Leider konnte keine Verbindung zum Server hergestellt werden. (Grund: %s)"
----------------------------------------------
Hi
Wahrscheinlich die Schreibweise. Die O-Notation wird hin und wieder
verkürzt (durch n geteilt) bzw ist das 'O' eigentlich zwei verschiedene
Buchstaben, zwei verschiedene Angaben. Mach Dich einfach mal kundig über
"O-Notation", dsa Wiki ist hier glaueb ich ausnahmsweise gut, bin ich jetzt
aber zu faul, dsa zu kontrollieren.
Mein Inf-A-Vordiplom jährt sich zwar bald zum 15ten mal, aber ich hab doch
nix verwechselt. (Ich hab tatsächlich noch das "wunderbare Buch" zur
Vorlesung ausgegraben, das seit der Emiritierung der beiden Profs kein
Mensch mehr kauft, und ich bei jedem Umzug vergeblich wegzuschmeißen
versuche... :)
Ganz trivial: 2 geordnete Mengen, vergleiche die beiden kleinsten
Elemente, sind sie identisch dann sind sie im Schnitt und man streicht beide
ansonsten streicht man nur das kleinere. Das so lange bis eine Liste leer
ist.
»»
Ja, genau das meinte ich und das bedeutet eine Komplexität von
O(n*log(n)).
Nö, ich muss im Worstcase jedes _höchtens_insgesamt_genau_ 1 mal anfassen,
nicht jede Paarung.
Sei p,q die Länge zweier _geordneter_ Listen, dann braucht obiger Algo
höchstens p+q Vergleiche, desdewegen O(n) mit n=p+q.
Bitte genau lesen, ich _streiche_ die untersten Elemente in beide Listen,
beide sortiert und gehe linear weiter.
O(log(n)) bräuchte ich nur zum zusätzlichen Ordnen, wenns nicht bereits
wäre.
Ich glaub auch nicht dass es besser ginge als O(n), da sich für jeden
"besseren" Ansatz (z.B mit Baumsortierung) ein Gegenbeispiel konstruieren
ließe, wo doch jedes Element angefasst werden muss.
Und die Ordnung richtet sich ja nach der _maximalen_ Zeitkomplexität.
(Was nicht heißen soll, dass man im Schnitt nicht schnellere Ergebnisse
haben kann, z.B. Baumsortierung um ganze Teillisten auszuschließen, aber das
wäre jetzt für _mich_ Microoptimierung)
Du mußt jeden einmal anfassen (n), weil Du aber nach dem Vergleich
streichen kannst (bzw eine Suche in einer sortierten Liste bekannter Länge
eh nur log(n) dauert), mußt Du nicht n-mal vergleichen, sondern nur
log(n)-mal.
1. streiche ich in beiden listen
2. vergleiche ich immer nur die beiden untersten.
(rein formal müßte ich noch verlangen dass es in den Listen keine Duplikate
gibt, aber geschenkt oder?)
Habe ich das richtig erklärt Christian? Stimmt alles?
er würde dir vielleicht antworten ...
P=(3,8,23,56,89)
Q=(2,23,89,100)
1. 3 > 2 : 2 streichen
2. 3 < 23 : 3 streichen
3. 8 < 23 : 8 streichen
4. 23 = 23 : SCHNITT ,beide 23 streichen und zu S
5. 56 < 89 : 56 streichen
6. 89 = 89 : SCHNITT ,beide 89 streichen und zu S, P leer, also Ende
also S=(23,89)
Zeitkomplexität T(n)=6 Operationen, mit n=p+q=9!
Es gilt T(n)<n-s-x wobei x hier die Restlänge der übrigen Liste am Ende ist.
Überzeugt? >:)
Gute Nacht
Rolf
DENKAUFGABE: Wenn ich die Listen als Startwert und Deltas abspeichere
klappts genauso schnell, hehehe. Wieso?
NACHTRAG:
Christian hat mir in der Zwischenzeit gemailt, hier mit meiner Antwort
----------------------------------------------
...
Bitte genau lesen, ich _streiche_ die untersten Elemente in beide Listen,
beide sortiert und gehe linear weiter.
Bei einer geordneten Liste musst du zusaetzlich den Sortierungsaufwand
betrachten. Der ist, ich wuerde in diesem Fall sinnvollerweise Insertion Sort
benutzen, O(n^2), stabil.
Seufz, meinetwegen O(n^4), das sit hier irrelevant weil die Listen sowieso beim Zeitpunkt der Suche bereits sortiert sind. Red ich schwedisch?
O(log(n)) bräuchte ich nur zum zusätzlichen Ordnen, wenns nicht bereits
wäre.
*ROTFL* Den Algorithmus moechte ich sehen. Nein, der niedrigste Aufwand zum
sortieren ist O(n*log(n)). Kleiner kriegt mans beim besten Willen nicht.
Vergl. auch http://de.wikipedia.org/wiki/Sortieralgorithmus -- da steht der
Beweis. Den haben wir in der Vorlesung "Einfuehrung in die Informatik II"
gemacht :))
OK hirnlos falsch abgeschrieben, mea culpa ... aber wie gesagt ist Sortierung hier NICHT relevant weil ich beim Archivieren der Postings einfach die ID an die Liste anhängen möchte.
Oder plant ihr zufällige IDs einzuführen? ;)
Deswegen kostet mich der Schnitt nur O(n), Basta!
Tschau
Rolf
你好 LanX²,
Bitte genau lesen, ich _streiche_ die untersten Elemente in beide
Listen, beide sortiert und gehe linear weiter.Bei einer geordneten Liste musst du zusaetzlich den Sortierungsaufwand
betrachten. Der ist, ich wuerde in diesem Fall sinnvollerweise
Insertion Sort benutzen, O(n^2), stabil.Seufz, meinetwegen O(n^4), das sit hier irrelevant weil die Listen
sowieso beim Zeitpunkt der Suche bereits sortiert sind. Red ich
schwedisch?
Darum ging es doch gar nicht, moensch. Ich wollte es nur klar haben. Red
ich schwedisch? >;)
O(log(n)) bräuchte ich nur zum zusätzlichen Ordnen, wenns nicht
bereits wäre.*ROTFL* Den Algorithmus moechte ich sehen. Nein, der niedrigste
Aufwand zum sortieren ist O(n*log(n)). Kleiner kriegt mans beim besten
Willen nicht. Vergl. auch http://de.wikipedia.org/wiki/Sortieralgorithmus -- da steht der
Beweis. Den haben wir in der Vorlesung "Einfuehrung in die Informatik
II" gemacht :))OK hirnlos falsch abgeschrieben, mea culpa ... aber wie gesagt ist
Sortierung hier NICHT relevant weil ich beim Archivieren der Postings
einfach die ID an die Liste anhängen möchte.Oder plant ihr zufällige IDs einzuführen? ;)
Es wird asynchron archiviert. Du kannst nicht einfach anhaengen.
再见,
CK
Hi
Es wird asynchron archiviert. Du kannst nicht einfach anhaengen.
Hmm, Synchronisierungsaufwand? ... OK am besten Einsetzen statt Anhängen mit gelockter Liste.
Tschau
rolf
Hi,
NACHTRAG: weil letzte Nacht der Server um 4:30 abgestüzt war, (deswegen gings sicherheitshalber schonmal als mail an christoph und christian raus.)
Jaja, man sollte doch immer kurz vor dem Abschicken des Posts nochmal schauen, ob sich nicht doch noch jemand gemeldet hat.
Da eine Mail privat ist, muß ich hier vor einem C&P erst mal fragen, ob ich das auch darf:
Darf ich?
so sort
Christoph Zurnieden
hi
Da eine Mail privat ist, muß ich hier vor einem C&P erst mal fragen, ob ich das auch darf:
Darf ich?
ich habe mich bereits drüber hinwegesetzt. hoffentlich ist mir CK jetzt nict bös ... :)
tschau
rolf
Hi
So funktioniert eine DB nicht, das ist da schon etwas geschickter geregelt. Wenn ich mein "endlich mal meine Boomarks aufräumen" ...
ich glaub euch sofort das DB nahe am optimum arbeiten, allerdings von generellen szenarien ausgehend.
Nein, sondern genau dafür, wofür das Dingen ursprünglich gedacht war: um auf einfache Weise nachschauen zu können, ob mit einer recht genau bestimmbaren Wahrscheinlichkeit etwas gecached wurde.
Also mein Cache ist ein Hash in das ich sowieso direkt nachschaue, und statt dessen soll ich x Hashfkten eines Filters starten, der mir nur eine probalistische Aussage gibt, ob mein Wort im Cache ist???
Selbst ob die JS-Ausage "liegt im Cache" hilft mir _hier_ viel hilft, wenn ich im Gegenzug bei jedem Cachen den Filter aktualisieren muss?
Warum nicht gleich als fertige Seite?
Hä? Soll ich zu jedem Wort eine Liste mit HTML-Code der gesuchten Seiten vorhalten???
Ach so, du meinst nur die Ausgabe auf die Suche? das macht 1. bei Mehrwortsuche keinen Sinn, und 2. das generieren der Seite kann nicht wirklich viel teurer sein als sie fertig umzukopieren.
Brächte Vorteile wenn man nur die Differenzen abspeichern muß, desto mehr Listen passen ins RAM.
Das ist Microoptimierung, vergiss es schnell wieder.
(Du verbrauchst fast schon mehr Zeit diese Differenzen zu erstellen, als sie nachher gewinnen)
wieso, Integeraddition ist mit das billigste was ein Prozessor kann
(bereits früher auf dem 68000er 4 Zyklen), wenn dafür doppelt soviele Listen ins RAM passen und ich dafür sehr viele Plattenzugriffe einspare lohnt es sich extremst.
Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden.
... und schon ist das RAM voll.
nein die liegen doch auf der Platte!
Wenn ich damit performant auf Zellen der K-Hashes zugreifen kann, gerne.
Wie denn sonst?
ich steck da im Detail nicht drinnen wann etwas fragmentiert wird, wie die Blockgrenzen laufen, und was daraus für ein Overhead resultiert.
Wenn das alles keine Rolle spielt, gerne.
Die Bäume einer DB sind doch auf viel generellere Anforderungen hin optimiert, die hier gar nie auftreten werden. Z.B. müssen hier nicht täglich Millionen Postings eingetragen werden
Skalierbarkeit hat hier wenig mit zu tun.
Nein, aber ich denke diese B-Bäume sind auch optimiert zum schnellen Einpflegen und organisieren sehr vieler Daten.
Bye
rolf
Hi
Selbst ob die JS-Ausage "liegt im Cache" hilft mir _hier_ viel hilft, wenn ich im Gegenzug bei jedem Cachen den Filter aktualisieren muss?
Gut, das hängt von der Cachestrategie ab ... die Sache mit dem Auslagern des Cachetests auf die Clientseite hat zugegeben was geniales :), von der Aufwandsbilanz ist es aber IMHO etwas unsauber, da ich hier quasi Parallelcomputing betreibe, wobei die Gesamtbilanz schlechter wird. Zugegebenerweise wird der Server geschont, obwohl in die Bilanz müsste das jetzt jedesmal Code + Daten des Bloomfilters zusätzlich ausgeliefert werden müßten.
Tschau
Rolf
Hi
So funktioniert eine DB nicht, das ist da schon etwas geschickter geregelt. Wenn ich mein "endlich mal meine Boomarks aufräumen" ...
ich glaub euch sofort das DB nahe am optimum arbeiten, allerdings von generellen szenarien ausgehend.
Ja, und warum solte das hier kein generelles Szenario sein?
Nein, sondern genau dafür, wofür das Dingen ursprünglich gedacht war: um auf einfache Weise nachschauen zu können, ob mit einer recht genau bestimmbaren Wahrscheinlichkeit etwas gecached wurde.
Also mein Cache ist ein Hash in das ich sowieso direkt nachschaue, und statt dessen soll ich x Hashfkten eines Filters starten, der mir nur eine probalistische Aussage gibt, ob mein Wort im Cache ist???
Ja, denn das ist deutlich flexibler und es besteht auch noch die gute Möglichkeit, das der Server dabei nicht belastet wird.
Selbst ob die JS-Ausage "liegt im Cache" hilft mir _hier_ viel hilft, wenn ich im Gegenzug bei jedem Cachen den Filter aktualisieren muss?
Das mußt Du gar nicht, denn das Dingen ist fehlertolerant und es damit ist auch nicht tödlich, wenn das Dingen veraltet, denn das tut es nur direkt proportional zur Änderung im Cache.
Wie Du schon richtig festgestellt hast: das Ding arbeitet probabilistisch, die Exaktheit ist nicht wesentlich, die Masse macht's.
Ach so, du meinst nur die Ausgabe auf die Suche? das macht 1. bei Mehrwortsuche keinen Sinn, und 2. das generieren der Seite kann nicht wirklich viel teurer sein als sie fertig umzukopieren.
Das Generieren der Seite beinhaltet aber eine DB-Anfrage, fertige Seiten könnte man im RAM halten. Wird zu groß? Mal schauen:
Ich such einmal ganz doof nach "Javascript", das ergibt 100 Treffer, Maximum erreicht, er sucht sonst nirgendwo. Gut, das ist jetzt kein ideales Beispiel, das man cachen sollte, aber die Größe dürfte maximal sein: gute 90 kib, gzipped gute 20 kib. gehe ich mal ganz uveschämt von etwas aus, und zwar von 4 kib großen RAM-Kartons, dann sind das pro Seite 5, na, besser 6 Boxen, macht 24 Kib, macht runde 42 Seiten pro Emmchen. 10 Emmchen lassen sich immer irgendwo abzweigen, darin kann man also theoretisch runde 420 Seiten vorhalten. Gut, aber abzüglich der nötigen Verwaltung bestimmt immer noch rund 400 Seiten. Die 400 Top-Suchbegriffe des Vortages derart preiswert vorhalten zu können fände ich doch recht angenehm.
Das ist Microoptimierung, vergiss es schnell wieder.
(Du verbrauchst fast schon mehr Zeit diese Differenzen zu erstellen, als sie nachher gewinnen)wieso, Integeraddition ist mit das billigste was ein Prozessor kann
(bereits früher auf dem 68000er 4 Zyklen), wenn dafür doppelt soviele Listen ins RAM passen und ich dafür sehr viele Plattenzugriffe einspare lohnt es sich extremst.
Ja, ich weiß, ich hätte mir die Klammer saren sollen, das war ja schon fast Microoptimierung bei mir.
Das eigentliche Problem ist dabei, das Deine Geschichte immer komplexer wird. Simplizität ist aber auch ein wichtiges Kriterium für einen Algorithmus, wenn er in Code umgesetzt werden soll. Da die Listen komprimiert werden können und wahrscheinlich auch sollten ist eigentlich jedem klar, sollte es zumindest sein. Das ändert aber nichts am eigentlichem Algorithmus. Erster Gedanke sollte also sein: "Gibt es einen besseren Algorithmus?" und nicht "Wie läßt sich der Algorithmus hier im Detail verbessern?". Zu "besser" kann natürlich auch "einfacher" gehören, selbst wenn es evt ein klein wenig langsamer ist.
Mensch, aber selbst wenn, sorry ... wenn das Vokabular sich verdoppelte, müssten halt alle K-Hashes es auch werden. Das sind Sekunden.
... und schon ist das RAM voll.
nein die liegen doch auf der Platte!
Und das ist schneller?
Wenn ich damit performant auf Zellen der K-Hashes zugreifen kann, gerne.
Wie denn sonst?
ich steck da im Detail nicht drinnen wann etwas fragmentiert wird, wie die Blockgrenzen laufen, und was daraus für ein Overhead resultiert.
Wenn das alles keine Rolle spielt, gerne.
Bei so kleinen Dingern und ReiserFS kannst Du das getrost ignorieren.
Die Bäume einer DB sind doch auf viel generellere Anforderungen hin optimiert, die hier gar nie auftreten werden. Z.B. müssen hier nicht täglich Millionen Postings eingetragen werden
Skalierbarkeit hat hier wenig mit zu tun.
Nein, aber ich denke diese B-Bäume sind auch optimiert zum schnellen Einpflegen und organisieren sehr vieler Daten.
Ja, aber read-only sind sie alle ziemlich gleich. DB-Benchmarks kannst Du normalerweise sofort in die Tonne hauen, wenn Du nicht gerade _genau_ darauf testest, was Du nachher brauchst. Deshalb steht es in den Nutzungsbedingungen einiger DB-Hersteller sogar drin, das Du keine Benchmarks veröffentlichen darfst.
so short
Christoph Zurnieden
Hi,
und, gut rübergekommen alle?
Ich denke Hashtabllen sind ziemlich unschlagbar.
Hash-Tabellen sind bei grossen Datenmengen recht unbrauchbar, weil es zu
viele Dubletten gibt. Je mehr Daten auf einen begrenzten Raum abgebildet
werden muessen, desto mehr Dubletten gibt es.
Ähm ... nein, das ist so nicht ganz korrekt. Ärger mit Doubletten gibt es wenn die Menge der Daten die Menge der (Primär-)Schlüssel überschreitet. Das passiert aufgrund einer schlechten Hashfunktion. Nein, das ist _immer_ wg einer schlechten, oder sollte ich besser sagen: unpassenden Hashfunktion.
Kennst Du alle Daten vorher ist es natürlich ein leichtes eine perfekte Hashfunktion zu basteln, dafür gibt es sogar passende Tools (z.B. gperf(1)). Kennst Du sie nicht, hast Du die von Dir beschriebenen Probleme. Die tauchen aber auch auf, wenn die Hashtabelle eigentlich groß genug ist, die Hashfunktion aber die gegebenen Daten nicht gleichmäßig verteilen kann. Die Kenntnis der Menge der Daten schützt also auch nicht vor Doubletten.
Sind weder Menge noch Art der Daten vorher bekannt[1]: naja, dann sollte man eben andere Methoden als eine Hashtabelle benutzen. In Falle des Selfhtmlarchivs wäre das z.B. ein binärer Baum. Ideal wäre hier ein symmetrischer, niedriger Baum und da die einzelnen Datenstücke auch relativ groß sind würde sich ein B+-Baum empfehlen, noch besser Niemans B++-Baum. Womit wir dann, mein lieber rolf/LanX!, schlußendlich bei einer ausgewachsenen DB wären.
so short
Christoph Zunrieden
[1] natürlich ist die Art der Daten vorher bekannt, nur eben nicht _vollständig_. Knapp daneben ist in diesem Falle eben auch vorbei.
你好 Christoph,
und, gut rübergekommen alle?
Sischer, siehst du ja.
Ich denke Hashtabllen sind ziemlich unschlagbar.
Hash-Tabellen sind bei grossen Datenmengen recht unbrauchbar, weil es zu
viele Dubletten gibt. Je mehr Daten auf einen begrenzten Raum abgebildet
werden muessen, desto mehr Dubletten gibt es.Ähm ... nein, das ist so nicht ganz korrekt. Ärger mit Doubletten gibt
es wenn die Menge der Daten die Menge der (Primär-)Schlüssel
überschreitet.
Aerger mit Dupletten gibt es, wenn man einen (theoretisch) unbegrenzten
Raum auf einen begrenzten Raum abbilden will.
Das passiert aufgrund einer schlechten Hashfunktion. Nein, das ist
_immer_ wg einer schlechten, oder sollte ich besser sagen: unpassenden
Hashfunktion.
“Unpassend” ist unpassend, richtiger waere, einer nicht-optimalen
Hash-Funktion. Der Preis der Generalisierung.
Kennst Du alle Daten vorher ist es natürlich ein leichtes eine
perfekte Hashfunktion zu basteln, dafür gibt es sogar passende Tools
(z.B. gperf(1)).
Das stimmt so nicht, auch gperf kann uU keine perfekte Hash-Funktion
schreiben. Das haengt von der Schluesselmenge und der Art der Schluessel
ab. Manchmal ist es einfach nicht moeglich, eine Perfekte Hash-Funktion zu
erstellen.
Whatever, wollte man mit einer perfekten Hash-Funktion arbeiten, muesste
man damit leben, dass zumindest Teiles des Codes hochspezialisiert auf
_genau_ die Daten zugeschnitten sind. IMHO ein Kompromiss, mit dem man
bei einer Suche nicht leben kann. Daher war ich von einer generalisierten
Hash-Funktion, wie sie z. B. auch von Datenbanken oder Script-Sprachen
benutzt wird, ausgegangen.
Sind weder Menge noch Art der Daten vorher bekannt[1]: naja, dann
sollte man eben andere Methoden als eine Hashtabelle benutzen.
Meine Rede ;-)
In Falle des Selfhtmlarchivs wäre das z.B. ein binärer Baum.
Ideal wäre hier ein symmetrischer, niedriger Baum und da die einzelnen
Datenstücke auch relativ groß sind würde sich ein B+-Baum empfehlen,
noch besser Niemans B++-Baum.
Ein B+-Baum ist kein Binaerbaum, auch kein binaerer Baum :) Aber
prinzipiell gebe ich dir recht, eine Form des B-Baums waere wesentlich
angebrachter. (Unterschiede zwischen Binaerbaum und
B-Baum bitte in der Wiki nachlesen).
再见,
CK
Hi,
Aerger mit Dupletten gibt es, wenn man einen (theoretisch) unbegrenzten
Raum auf einen begrenzten Raum abbilden will.
Mmh... was mach ich jetzt. Werde ich mathematisch, was dann nur noch 4-5 Leute im Forum verstehen (Mich selbst nicht unbedingt mit eingeschlossen ;-) oder lasse ich das einfach mal so stehen?
Das passiert aufgrund einer schlechten Hashfunktion. Nein, das ist
_immer_ wg einer schlechten, oder sollte ich besser sagen: unpassenden
Hashfunktion.“Unpassend” ist unpassend, richtiger waere, einer nicht-optimalen
Hash-Funktion.
Wenn eine optimale Hashfunktion gesucht wird ist eine nicht-optimale Hashfunktion unpassend.
Oder nicht?
Der Preis der Generalisierung.
Es ist eine Definitionsfrage, wieviele Details eine Generalisierung zuläßt.
Manchmal ist es einfach nicht moeglich, eine Perfekte Hash-Funktion zu erstellen.
Es ist _immer_ möglich eine perfekte Hashfunktion zu erstellen. Wenn sich die Daten rein gar nicht komprimieren lassen ist die Hashfunktion eine direkte Abbildung. Zwar zu nix mehr zu gebrauchen, aber immer noch "perfekt".
In Falle des Selfhtmlarchivs wäre das z.B. ein binärer Baum.
Ideal wäre hier ein symmetrischer, niedriger Baum und da die einzelnen
Datenstücke auch relativ groß sind würde sich ein B+-Baum empfehlen,
noch besser Niemans B++-Baum.Ein B+-Baum ist kein Binaerbaum, auch kein binaerer Baum :)
Ja, warum ... oh, 'tschuldigung, sollte mir doch mal angewöhnen, meine Postings vor dem Abschicken noch mal etwas genauer unter die Lupe zu nehmen. Da ist wohl etwas ungeschickt formuliert worden, weiter als bis 1 kann ich schon noch zählen ;-)
so short
Christoph Zurnieden
你好 Christoph,
Das passiert aufgrund einer schlechten Hashfunktion. Nein, das ist
_immer_ wg einer schlechten, oder sollte ich besser sagen: unpassenden
Hashfunktion.“Unpassend” ist unpassend, richtiger waere, einer nicht-optimalen
Hash-Funktion.Wenn eine optimale Hashfunktion gesucht wird ist eine nicht-optimale
Hashfunktion unpassend.
Oder nicht?
Wer sagt denn, dass eine optimale Hash-Funktion gesucht wird? Ich nicht.
Manchmal ist es einfach nicht moeglich, eine Perfekte Hash-Funktion
zu erstellen.Es ist _immer_ möglich eine perfekte Hashfunktion zu erstellen. Wenn
sich die Daten rein gar nicht komprimieren lassen ist die Hashfunktion
eine direkte Abbildung. Zwar zu nix mehr zu gebrauchen, aber immer
noch "perfekt".
Das ist jetzt Definitions-Sache.
再见,
CK
Hi,
Wer sagt denn, dass eine optimale Hash-Funktion gesucht wird? Ich nicht.
Nein, das habe natürlich ich gesagt. War Teil meiner Argumentation. Nur habe ich keine Bindestrichwortungetüme vor denen es schon Tucholsky grauste gebastelt sondern das Adjektiv "unpassend" gewählt. Das fandest Du wiederum unpassend und hast auf dem fast schon gargantuesken "nicht-optimal" bestanden.
Das hatte mich amüsiert und zu einem - zugegebenermaßen recht lahmen - Wortspiel verleitet. Ich habe aber bereits die dabei fällig gewordenen zwei Euro in die Wortwitzkasse geworfen. Das Schweinchen füllt sich also wieder.
Das ist jetzt Definitions-Sache.
Das war es vorher ebenfalls, deshalb habe ich es getan, wenn auch nicht formal. Du wolltest ja nicht?
so short
Christoph Zurnieden
你好 Christoph,
Wer sagt denn, dass eine optimale Hash-Funktion gesucht wird? Ich nicht.
Nein, das habe natürlich ich gesagt. War Teil meiner Argumentation.
Nur habe ich keine Bindestrichwortungetüme vor denen es schon Tucholsky
grauste gebastelt sondern das Adjektiv "unpassend" gewählt. Das fandest
Du wiederum unpassend und hast auf dem fast schon gargantuesken
"nicht-optimal" bestanden.
Was ich damit aussagen wollte: ich habe auf “nicht-optimal” bestanden,
weil ich dir widersprochen habe in der Aussage, dass eine perfekte
Hashing-Funktion gesucht wird. Wird IMHO ganz und gar nicht, da sich der
Datenbestand (wahrscheinlich sogar taeglich) von seiner Art (in Hinblick
auf die Hashing-Funktion) aendert.
Das hatte mich amüsiert und zu einem - zugegebenermaßen recht
lahmen - Wortspiel verleitet. Ich habe aber bereits die dabei fällig
gewordenen zwei Euro in die Wortwitzkasse geworfen. Das Schweinchen
füllt sich also wieder.
Hehe ;-)
Das ist jetzt Definitions-Sache.
Das war es vorher ebenfalls, deshalb habe ich es getan, wenn auch nicht
formal. Du wolltest ja nicht?
Ich finde es halt laecherlich, eine direkte Abbildung als perfekte
Hashing-Funktion zu bezeichnen. Denn perfekt beinhaltet ja nicht nur
die Tatsache, dass es keine Duplikate geben darf.
再见,
CK
Hi,
Was ich damit aussagen wollte: ich habe auf “nicht-optimal” bestanden,
weil ich dir widersprochen habe in der Aussage, dass eine perfekte
Hashing-Funktion gesucht wird. Wird IMHO ganz und gar nicht, da sich der
Datenbestand (wahrscheinlich sogar taeglich) von seiner Art (in Hinblick
auf die Hashing-Funktion) aendert.
Und warum sollte dafür keine perfekte Hashfunktion gefunden werden können?
Wenn Du davon ausgehst, das sich die Menge asymptotisch dem Unendlichem annähert ist es korrekt, das sich diese Menge nicht mehr komprimieren läßt: die Hälfte von Unendlich ist ja immer noch unendlich. Dazu müßte die Schlüsselmenge also auch unendlich sein, das geht nur bei direkter Abbildung. Das, was hast Du ja weiter unten als "lächerlich" bezeichnet hast und nun zur Untermauerung _Deines_ Argumentes dient. Mit ein wenig Mühe und gespitztem Bleistift ließe sich daraus sogar ein formal korrekter Beweis basteln. Das geht dann aber nur, wenn Du die 1:1 Abbildung als "perfekten Hash" akzeptierst und nicht sofort als lächerlich abtust. Auch wenn der äußerliche Anschein durchaus zum Lachen reizt, zugegeben.
Deshalb werden ja auch willkürliche Grenzen gesetzt, der Begriff "Hashing" wird je nach Einsatzzweck genau definiert eingegrenzt. Im Bereich Computertechnik ist die schnellste Methode des Zugriffs die direkte Adressierung. Diese Adresse hat eine bestimmte Größe und wird deshalb gerne als Obergrenze der Schlüssellänge benutzt. In einem gängigem x86-32 sind das z.B. 32 Bit und in einem modernem 64-Bit Rechner sind das 64-Bit, wie der Name schon anzudeuten versucht.
Erstens also: die Größe der Hashtabelle sollte 2^32 respektive 2^64 Schlüsselpaare nicht überschreiten.
Worst Case einer Hashtabelle ist O(n), Best Case O(1). Kollisionsbehandlung M addiert sich zu O(1), also O(1+M).
Zweitens also: M<<n, anzustreben: M = 0.
Diese beiden Punkte beschreiben die gängige Auffasung über Hashing, das in praxi anwendbar ist, ja: überhaupt erst Sinn macht. Die ganzen Diskussionen über "gute" oder "schlechte" Hashfunktionen behandeln also nur in mikrooptimierender Weise die Minimierung von M in sehr eng bestimmten Umgebungen und sind somit müßig. Schlechter als O(n) geht's nunmal nicht und wenn nicht alle Daten a priori bekannt sind, ist die Minimierung von M reines T&E. Eine große Sammlung der verschiedensten Hashfunktionen mit jeweils einer kurzen Notiz für welchen Zweck macht viel mehr Sinn als jede noch so abgehobene Diskussion darüber, was denn die Beste sei.
Hier bei der Archivsuche (Als typische Form des "text retrival") ist die effizienteste Art der Suche ein "inverted index" [Witten1999]. Der funktioniert bestens mit verschachtelten Hastables.
Nun ist sowas aber riesig und vollständige Updates würden einen umbringen. Was ist nun also günstiger: eine verzweifelte Suche nach der optimalen Hashfunktion oder Überlegungen bezüglich der optimalen Updatestrategie?
Beides natürlich: sämtlich Postings die archiviert worden sind, sind als "bekannte Daten" im Sinne der Möglichkeit einen perfekten Hash bauen zu können anzusehen. Jede Änderung eienr Hashfunktion verlnagt aber einen vollständigen Rebuild der Hastabelle. Es ist also zu überlegen, wie die Updates am besten auszusehen haben, damit so wenig wie möglich lose rumliegt (was Volltext durchsucht werden müßte = teuer), aber auch so selten wie möglich Updates des Indexes durchgeführt werden müssen.
Teilt man z.B. das Archiv in Jahres/Monats/Tagesringe, wird der vollständige Rebuild des Indexes auf jeweils einen solchen Ring beschränkt. Kostet ein wenig Overhead an Platz und noch weniger an Rechenzeit. Man kann natürlich den Monatsring in-place updaten und die Fragmentierung einmal monatlich durch Rebuild des Monatsringes ausbügeln und diesen Monatsring dann am Ende des Jahres in den Jahresring einbauen. Ist zwar auch mehr oder weniger eine Frage von T&E, zeigt aber deutlich mehr Effekt pro für's Hirn verbrannter Kalorie als komplizierte Hashfunktionsoptimierung. Diese Optimierung ergibt sich sogar von selber, denn für jeden vollständigen Jahresring kannst Du perfekte Hashes basteln. Jedes Jahr erhöht sich dann M um 1, nach zehn Jahren hättest Du dann O(1+10), bei einem n von mehreren Millionen.
Wenn ich aber durch die Zahlen hinter den Forumsjahresarchiven (Hey, das Häckchen bei "Groß/Kleinschriebung beachten" ist ja weg!) mal einen Strich ziehe und schaue, wo der in zehn Jahren endet, wäre ein vorrausschauendes Indexmanagment wahrlich keine schlechte Idee.
So ungefähr hätte Deine Entgegnung auf meine Dreistigkeit aussehen können, aber Du mußtest ja unbedingt von "lächerlich" sprechen. Das ist jetzt die unverdiente Strafe.
so short
Christoph Zurnieden
Bibliographie:
{Witten1999} - Witten, I. H., Moffat, A. & Bell, T. C. (1999), Managing Gigabytes: Compressing and Indexing Documents and Images, second edn, Morgan Kaufmann, San Francisco, California.
你好 Christoph,
Was ich damit aussagen wollte: ich habe auf “nicht-optimal” bestanden,
weil ich dir widersprochen habe in der Aussage, dass eine perfekte
Hashing-Funktion gesucht wird. Wird IMHO ganz und gar nicht, da sich der
Datenbestand (wahrscheinlich sogar taeglich) von seiner Art (in Hinblick
auf die Hashing-Funktion) aendert.Und warum sollte dafür keine perfekte Hashfunktion gefunden werden
können?
Das habe ich nicht gesagt. Nochmal: ich sagte, ich suche keine. Ich will
nicht staendig am Source, und sei es auch automatisiert, rumbasteln
muessen (bei einer automatisierten Anpassung des Source koennen Fehler
passieren; ohne einen Beweis der Korrektheit des Algorithmus ein IMHO
nicht akzeptables Risiko).
Aber du hast mich auf einen zweiten Gedanken gebracht. Daran, dass bei
jeder Aenderung der Hash-Funktion der Index neu gebaut werden muss, bin
ich zugegebenerweise noch gar nicht gekommen. Du hast damit aber
vollkommen recht.
So ungefähr hätte Deine Entgegnung auf meine Dreistigkeit aussehen
können, aber Du mußtest ja unbedingt von "lächerlich" sprechen. Das ist
jetzt die unverdiente Strafe.
Hehe, damit hast du mich sicher nicht bestraft. Und da du selber schon
sagtest “Zwar zu nix mehr zu gebrauchen, aber immer noch "perfekt".” war
ich davon ausgegangen, dass meine Begruendung vollkommen ausreichend
war.
再见,
CK
Hi,
Und warum sollte dafür keine perfekte Hashfunktion gefunden werden
können?Das habe ich nicht gesagt.
Natürlich nicht, das sagte ich ja.
Nochmal: ich sagte, ich suche keine.
Nochmal: ich sage das, nicht Du, da hast Du vollkommen Recht.
Die Aufregung ist in diesem Fall sowieso vergeblich, da obige Frage nur eine rethorische ist: ein Haken, an dem ich meinen ganzen Sermon abgeseilt habe.
»»(bei einer automatisierten Anpassung des Source koennen Fehler passieren; ohne einen Beweis der Korrektheit des Algorithmus ein IMHO nicht akzeptables Risiko).
Einen kleinen Hinweis kann ich mir aber nicht verkneifen: dem Rechner kann es nicht passieren, das er irgendwo etwas vergißt oder sich vertippt.
Der entscheidende Vorteil eines Compilers übrigens.
Zum Thema automatisierbares Hashfunktionsändern siehe übrigens "Peter K. Pearson, fast hashing of variable length text strings. Communications of the ACM, 1990,33", der hat eine Hashfunktion vorgeschlagen, die recht einfach zu ändern ist, ohne das die Menge an Kollisionen sich signifikant ändert. Aber ich habe da im Augenblick keinen direkten Zugriff drauf. Falls mich meine Erinnerung da nicht getäuscht hat und Du an die Ausgabe rankommst, könntest Du mir den Artikel ja mal zukommen lassen. Nein, sowas würde unter Privatkopie laufen und ist immer noch legal. Egal was die Publikatoren sagen. Zumindest die eine Kopie. Ich würde mir ja auch gerne den Artijel bei ACM.org käuflich erwerben, aber ich habe keine Kreditkarte (Kreditkarte ist bei mir einfach zu gefährlich, dafür gibt es viel zu viele schöne und völlig sinnlose Sachen im Netz zu erwerben).
so short
Christoph Zurnieden
你好 Christoph,
Und warum sollte dafür keine perfekte Hashfunktion gefunden werden
können?Das habe ich nicht gesagt.
Natürlich nicht, das sagte ich ja.
So stellte es sich fuer mich dar. Wenn du das nicht so meintest, ist ja
alles ok.
Die Aufregung ist in diesem Fall sowieso vergeblich, da obige Frage nur
eine rethorische ist: ein Haken, an dem ich meinen ganzen Sermon
abgeseilt habe.
Hehe, ja, das war mir schon klar ;-)
(bei einer automatisierten Anpassung des Source koennen Fehler
passieren; ohne einen Beweis der Korrektheit des Algorithmus ein
IMHO nicht akzeptables Risiko).Einen kleinen Hinweis kann ich mir aber nicht verkneifen: dem Rechner
kann es nicht passieren, das er irgendwo etwas vergißt oder sich
vertippt. Der entscheidende Vorteil eines Compilers übrigens.
Mag ja sein, aber der Code-erzeugende Algorithmus kann fehlerhaft sein.
[...] Falls mich meine Erinnerung da nicht getäuscht hat und Du an die
Ausgabe rankommst, [...]
Ich wuesste nicht wie. Ich koennte mal in der Fachbereichsbibliothek
nachschauen, aber ich bezweifele es ehrlich gesagt.
[...] könntest Du mir den Artikel ja mal zukommen lassen. Nein, sowas
würde unter Privatkopie laufen und ist immer noch legal.
Ja, das weiss ich :)
(Kreditkarte ist bei mir einfach zu
gefährlich, dafür gibt es viel zu viele schöne und völlig sinnlose
Sachen im Netz zu erwerben).
Hehe, ja, dito.
再见,
CK
Hi,
Einen kleinen Hinweis kann ich mir aber nicht verkneifen: dem Rechner
kann es nicht passieren, das er irgendwo etwas vergißt oder sich
vertippt. Der entscheidende Vorteil eines Compilers übrigens.Mag ja sein, aber der Code-erzeugende Algorithmus kann fehlerhaft sein.
Es heißt ja eigentlich, das man seine Eltern ehren solle?
[...] Falls mich meine Erinnerung da nicht getäuscht hat und Du an die
Ausgabe rankommst, [...]Ich wuesste nicht wie. Ich koennte mal in der Fachbereichsbibliothek
nachschauen, aber ich bezweifele es ehrlich gesagt.
Ist auch nicht gar so wichtig, wer liest denn schon die hintendran gelistete Literatur? Doch nur die Autoren und auch nur die Liste, ob sie denn auch brav alle vorkommen. Hätte mich auch nur mal interessiert, ob ich richtig liege.
Die Hashfunktion selber habe ich gefunden, da sie mit passender Quellangabe an der einen oder anderen Stelle verbraten wurde (Google.de spuckte als erstes Ghostscript aus):
Ist ein bunt durchmischter Bytehaufen (genauer: eine zufällige Permutation der Werte von 0-255), der einem Schieberegister als Seed dient. Die Leute von Alladin behaupten, das das folgendes Array das Originale wäre:
uint8_t hash_seed[256]={
1,87,49,12,176,178,102,166,121,193,6,84,249,230,44,163,
14,197,213,181,161,85,218,80,64,239,24,226,236,142,38,200,
110,177,104,103,141,253,255,50,77,101,81,18,45,96,31,222,
25,107,190,70,86,237,240,34,72,242,20,214,244,227,149,235,
97,234,57,22,60,250,82,175,208,5,127,199,111,62,135,248,
174,169,211,58,66,154,106,195,245,171,17,187,182,179,0,243,
132,56,148,75,128,133,158,100,130,126,91,13,153,246,216,219,
119,68,223,78,83,88,201,99,122,11,92,32,136,114,52,10,
138,30,48,183,156,35,61,26,143,74,251,94,129,162,63,152,
170,7,115,167,241,206,3,150,55,59,151,220,90,53,23,131,
125,173,15,238,79,95,89,16,105,137,225,224,217,160,37,123,
118,73,2,157,46,116,9,145,134,228,207,212,202,215,69,229,
27,188,67,124,168,252,42,4,29,108,21,247,19,205,39,203,
233,40,186,147,198,192,155,33,164,191,98,204,165,180,117,76,
140,36,210,172,41,54,159,8,185,232,113,196,231,47,146,120,
51,65,28,144,254,221,93,189,194,139,112,43,71,109,184,209
};
Hashfunktion selber ist ein simples Schieberegister. Daran gäbe es einiges zu mäkeln, ich gebe es hier aber unverändert wieder (zwar Typen aufgelöst, aber nicht passend gemacht):
uint32_t pearson_hash(const unsigned char *s, size_t length){
uint32_t hash = 0;
size_t n = length;
while(--n > 0){
hash = (hash << 8) |
hash_seed[(unsigned char)hash ^ *s++];
}
return hash;
}
Wenn die Permutationen des Seedarrays echt(!) zufällig sind, erzeugt jede solcher Permutationen eine gleichwertige Hashfunktion. Die Qualität dürfte sich dabei im einheitlichem Rahmen bewegen: nicht gerade spitze, aber auch nicht wirklich schlecht. Wäre evt interessant für Kollisionsbehandlung mittels weiterer Hashfunktionen aber auch - und sogar vor allem für Bloomfilter [Bloom1970]. Eine schmählich vernachlässigte Erfindung. Siehe auch http://www.cs.wisc.edu/~cao/papers/summary-cache/node8.html ff. für eine kurze Übersicht.
[...] könntest Du mir den Artikel ja mal zukommen lassen. Nein, sowas
würde unter Privatkopie laufen und ist immer noch legal.Ja, das weiss ich :)
Du warst ja auch nicht wirklich gemeint, aber bei der heutzutage herrschenden künstlichen Hysterie auf dem Gebiet dachte ich mir: schreib's lieber nochmal dran, man weiß ja nie wer mitliest.
so short
Christoph Zurnieden
Bibligraphie
{Bloom1970} Burton Bloom.
Space/time trade-offs in hash coding with allowable errors.
Communications of ACM, pages 13(7):422-426, July 1970
你好 Christoph,
Hashfunktion selber ist ein simples Schieberegister. Daran gäbe es
einiges zu mäkeln, ich gebe es hier aber unverändert wieder (zwar Typen
aufgelöst, aber nicht passend gemacht):uint32_t pearson_hash(const unsigned char *s, size_t length){
uint32_t hash = 0;
size_t n = length;while(--n > 0){
hash = (hash << 8) |
hash_seed[(unsigned char)hash ^ *s++];
}
return hash;
}
Hm, ich bin mir jetzt nicht sicher, aber eine gleichmaessige Verteilung
ist durch diese Funktion nicht gegeben, oder? Und wenn ich laenger
darueber nachdenke, Zufaelligkeit ist auch nicht wirklich gegeben...
Beispiel: k0-k9 muessten den gleichen Wert ergeben, da in diesem Fall nur
das k einbezogen wird, nicht jedoch die 0-9 (while(--n > 0)). Aendert
man das in while(n-- > 0), sieht es schon besser aus, aber die
gleichmaessige Verteilung ist immer noch nicht gegeben, oder?
再见,
CK
Hi,
uint32_t pearson_hash(const unsigned char *s, size_t length) [...]
Hm, ich bin mir jetzt nicht sicher, aber eine gleichmaessige Verteilung
ist durch diese Funktion nicht gegeben, oder? Und wenn ich laenger
darueber nachdenke, Zufaelligkeit ist auch nicht wirklich gegeben...
Beispiel: k0-k9 muessten den gleichen Wert ergeben, da in diesem Fall nur
das k einbezogen wird, nicht jedoch die 0-9 (while(--n > 0)). Aendert
man das in while(n-- > 0), sieht es schon besser aus, aber die
gleichmaessige Verteilung ist immer noch nicht gegeben, oder?
Ja, genau, dieses Snippet ist nicht wirklich gut, die Idee dahinter (Random Seed) ist es jedoch durchaus. (Die Sonderfälle mit den Stellen 0 und 1 werden tatsächlich extra behandelt, wie ein ausführlicherer Blick in den Ghostscript Code darlegte).
Die Verteilung dieser Implementation ist wirklich nicht gut, da hier der Seed mittels einer XOR-Verknüpfung von LSB des Schlüssels und einem Zeichen des Inputs bestimmt wird.
Aber wie gesagt: nur die Implementation ist Mist, die Idee selber ist nicht schlecht.
so short
Christoph Zurnieden
Hi,
Also alleine schon ein knappes Gig für die platzsparendste(!) Lösung!
ein knappes MB :) Oder scklucken deine Oktets 1KB?
Da steht nix von Gigabyte, da steht nur Gig. Ein Gigabit würde z.B. passen.
Aber in solche Fallen kann man an Neujahr schon mal tappen; genauso, wie sie zu Sylvester gerne mal gestellt werden - in der Sektlaune ;-)
Ich denke Hashtabllen sind ziemlich unschlagbar.
Hashtabellen sind nur dann erfolgreich, wenn alle, und ich meine _alle_, Daten vorher bekannt sind. Nur dann kann ein "perfect hash" erstellt werden, es gibt keine Kollisionen und es gilt O(1). Zudem ist der Hashwert nicht einfach bekant, sondern muß vorher berechnet werden: bei jedem Eintrag und bei _jeder_ Suche.
Dazu ist der Komfort des oben beschriebenen Primitivstindexes nicht sehr sonderlich, da würden sich mit Sicherheit alle beschweren.
der deckt aber m.E. 90% aller Abfragen ab, für den Rest braucht es noch den 2. Suchschritt zum Ausfiltern. (schätze weitere 9% suchen nach Phrasen wie "meines Erachtens")
Da nützen Schätzwerte wenig, das sollte zumindest mit etwas Statistik gestützt werden.
Aber wie Du selber schon herausgefunden hast: das funktioniert nicht nur mit Zeichenketten nicht, sondern erfordert auch, das alle die gleiche Rechtschreibung beachten.
Nein, eine simple Wortindizierung bringt es einfach nicht.
so short
Christoph Zurnieden
Hi
ein knappes MB :) Oder scklucken deine Oktets 1KB?
Da steht nix von Gigabyte, da steht nur Gig. Ein Gigabit würde z.B. passen.
leider auch nicht weil 3 Dezimalstellen 10 Binärstellen braucht (1024) und ein Byte nur 8 derselben hat :)
Aber in solche Fallen kann man an Neujahr schon mal tappen; genauso, wie sie zu Sylvester gerne mal gestellt werden - in der Sektlaune ;-)
Hei man it's Silvester not Sülvester! *fg*
(SCNR habe "Der Genetiv ist dem Dativ sein Tod" zu Weihnachten bekommen :)
http://www.spiegel.de/kultur/gesellschaft/0,1518,280021,00.html
Ich denke Hashtabllen sind ziemlich unschlagbar.
Hashtabellen sind nur dann erfolgreich, wenn alle, und ich meine _alle_, Daten vorher bekannt sind.
Die Wörter der deutschen Sprache sind bekannt ...
Nur dann kann ein "perfect hash" erstellt werden, es gibt keine Kollisionen und es gilt O(1). Zudem ist der Hashwert nicht einfach bekant, sondern muß vorher berechnet werden: bei jedem Eintrag und bei _jeder_ Suche.
Ja es braucht ne Hashfunktion die mit deutschen resp. "denglischen" Wörtern gut zurecht kommt (z.B. "Sylvester";). Gut angenommen mehrere Wörter werden auf den gleichen Hashwert abgebildet, so what. Ich kann ja an der Stelle eine Liste der paar zulässigen Wörter ablegen. Selbst wenn ich diese Liste linear durchsuchte, ist das immer noch effektiver als ne binäre Suche.
Da nützen Schätzwerte wenig, das sollte zumindest mit etwas Statistik gestützt werden.
Ich legte bereits mein Nutzerverhalten zugrunde das bereits atypisch spezialisiert ist d.h. bereits zu viele regexp enthält. Daniela geht ja von der gleichen Annahme aus.
Aber wie Du selber schon herausgefunden hast: das funktioniert nicht nur mit Zeichenketten nicht, sondern erfordert auch, das alle die gleiche Rechtschreibung beachten.
Die Frage wie man effektiv enthaltene Wortteile sucht, macht mir mehr sorgen. Wie macht es die DB?
Nein, eine simple Wortindizierung bringt es einfach nicht.
Nun es reicht ein Histogramm der Buchstaben- oder Silbenverteilung
im Archiv um ne effektive und stabile Hashfkt zu basteln, die einerseits ins RAM passt und Rechtschreibfehlertolerant ist.
Sowas gibts bestimmt schon irgendwo fertig ausgearbeitet.
so short
a bittle longer
rolf
Hi,
Hashtabellen sind nur dann erfolgreich, wenn alle, und ich meine _alle_, Daten vorher bekannt sind.
Die Wörter der deutschen Sprache sind bekannt ...
aber nicht konstant. Neuschöpfungen gibt es immer wieder. Wer wußte vor 20 Jahren, was ein "Handy" ist?
Außerdem reicht die deutsche Sprache bei weitem nicht aus. Fachsprache ist Englisch, da kommen sehr viele Fachbegriffe (z.B. Hash) vor.
Und außerdem gabs durchaus auch schon Unterhaltungen in Russisch, Chinesisch, Ungarisch, Französisch usw.
Oder Threads, in denen es um Latein ging.
Usw.
cu,
Andreas
Hi,
Außerdem reicht die deutsche Sprache bei weitem nicht aus. Fachsprache ist Englisch, da kommen sehr viele Fachbegriffe (z.B. Hash) vor.
Und außerdem gabs durchaus auch schon Unterhaltungen in Russisch, Chinesisch, Ungarisch, Französisch usw.
Oder Threads, in denen es um Latein ging.
deswegen schrieb ich:
"Nun es reicht ein Histogramm der Buchstaben- oder Silbenverteilung
im Archiv ..."
5 Lateinthreads werden also kaum eine in der Suchlänge messbare Verschiebungen ergeben.
Cheers
rolf
Hi,
ein knappes MB :) Oder scklucken deine Oktets 1KB?
Da steht nix von Gigabyte, da steht nur Gig. Ein Gigabit würde z.B. passen.
leider auch nicht weil 3 Dezimalstellen 10 Binärstellen braucht (1024) und ein Byte nur 8 derselben hat :)
Wer sagt denn das ein Byte 8 Bit hat?
Ne ne, nach zwei Glas Sekt komme ich schonmal auf dumme Scherze, aber das reicht noch lange nicht dafür, Lücken im Konzept zu haben ;-)
Aber in solche Fallen kann man an Neujahr schon mal tappen; genauso, wie sie zu Sylvester gerne mal gestellt werden - in der Sektlaune ;-)
Hei man it's Silvester not Sülvester! *fg*
Nein, Sylvester war schon richtig ;-)
Ich denke Hashtabllen sind ziemlich unschlagbar.
Hashtabellen sind nur dann erfolgreich, wenn alle, und ich meine _alle_, Daten vorher bekannt sind.
Die Wörter der deutschen Sprache sind bekannt ...
Das sag' mal den Postern hier ;-)
Die Frage wie man effektiv enthaltene Wortteile sucht, macht mir mehr sorgen. Wie macht es die DB?
"It depends" könnte man sagen, oder weniger höflich:"See the source, Luke!"
Wenn es aber um die Vergleiche im Baum selber geht: da ist es bei Strings z.B. ein mehr oder weniger geschicktes strstr(). Das macht es ja auch so aufwendig. Ein "*foo*" würde z.B. im schlimmstem Falle jeden Knoten anfassen müssen.
Nein, eine simple Wortindizierung bringt es einfach nicht.
Nun es reicht ein Histogramm der Buchstaben- oder Silbenverteilung
im Archiv um ne effektive und stabile Hashfkt zu basteln, die einerseits ins RAM passt und Rechtschreibfehlertolerant ist.
Sowas gibts bestimmt schon irgendwo fertig ausgearbeitet.
Nicht das ich wüßte.
<I>? >;->
so short
Christoph Zurnieden
Hi,
Hei man it's Silvester not Sülvester! *fg*
Nein, Sylvester war schon richtig ;-)
Unbelievable, da muss es auch noch einen griechischen Heiligen Sylvester geben...
"It depends" könnte man sagen, oder weniger höflich:"See the source, Luke!"
Wenn es aber um die Vergleiche im Baum selber geht: da ist es bei Strings z.B. ein mehr oder weniger geschicktes strstr(). Das macht es ja auch so aufwendig. Ein "*foo*" würde z.B. im schlimmstem Falle jeden Knoten anfassen müssen.
ufff... (helge schneider emulator modus) dat isch aber scheische!
Nicht das ich wüßte.
Ach, bestimmt, irgendwas mit Buchstabenquersumme, Wahrscheinlichkeitstabellen, Modulorechnung und Huffmanncodebäumen...
kurz gegoogelt: http://www.seg.rmit.edu.au/code/zwh-ipl/ behandelt z.B. den Themenkomplex...
bye
rolf
Hi,
Unbelievable, da muss es auch noch einen griechischen Heiligen Sylvester geben...
Google.de findet 4.980.000 Seiten mit Silvester und 4.380.000 mit Sylvester. Wenn man bei letzterem allerdings "Sylvester Stallone" abzieht ... ;-)
Das macht es ja auch so aufwendig. Ein "*foo*" würde z.B. im schlimmstem Falle jeden Knoten anfassen müssen.
ufff... (helge schneider emulator modus) dat isch aber scheische!
Deshalb ja auch:"Augen auf beim Regex Kauf!" ;-)
Nicht das ich wüßte.
Ach, bestimmt, irgendwas mit Buchstabenquersumme, Wahrscheinlichkeitstabellen, Modulorechnung und Huffmanncodebäumen...
kurz gegoogelt: http://www.seg.rmit.edu.au/code/zwh-ipl/ behandelt z.B. den Themenkomplex...
Na, wohl mehr ein Unterthema. Ich sehe auch nirgendwo das eigentliche Paper und kann das Experiment auch nicht nachvollziehen: "The experiments we performed involved the search and insertion of words extracted from large text collections. We used the Text REtrieval Conference (TREC)data in our experiments, which can only be obtained through participation in TREC or partially obtained by becoming a member of the Linguistic Data Consortium."
Vom Code her ist das aber auch nicht so sonderlich aufregend (eher schon suspekt: was hat es z.B. mit dem "magischem Samen" 1159241 auf sich, außer das es der untere Zwilling eines Primzahlzwillings ist?), das Du Dir jetzt die Mühe machen müßtest, mir alles rauszusuchen oder gar zu schicken. Es ist auch ziemlich unvollständig, wenn sich nicht aus dem Paper ergeben würde, das die tatsächlich alle Möglichkeiten genutzt haben und nur die Eigenleistung gelistet wurde.
Also: kein Treffer - weitersuchen oder <I> >;->
so short
Christoph Zurnieden
Lieber Chrystoph,
Google.de findet 4.980.000 Seiten mit Silvester und 4.380.000 mit Sylvester. Wenn man bei letzterem allerdings "Sylvester Stallone" abzieht ... ;-)
Auf deutsche Webseiten bezogen sind es 2.480.000/839.000 ohne "böse Miezekatze" und "Italian Stallion" abzuziehen :)
Das macht es ja auch so aufwendig. Ein "*foo*" würde z.B. im schlimmstem Falle jeden Knoten anfassen müssen.
ufff... (helge schneider emulator modus) dat isch aber scheische!
Deshalb ja auch:"Augen auf beim Regex Kauf!" ;-)
Bist du sicher dass eine DB nicht effektiver suchen kann als bei allen Knoten ein instr zu machen? Bitter ist das ...
(ich würd die Daten nach zumindest nach Bi- und Trigrammen organisieren, vielleicht mit Hashes - hehehe ;)
kurz gegoogelt: http://www.seg.rmit.edu.au/code/zwh-ipl/ behandelt z.B. den Themenkomplex...
Na, wohl mehr ein Unterthema. Ich sehe auch nirgendwo das eigentliche Paper und kann das Experiment auch nicht nachvollziehen:
Da hast du recht, es ging mir im wesentlichen darum anhand der Spitze die Existenz des Eisbergs zu belegen.
Für ne dezidierte Literaturrecherche fehlts mir auch am nötigen Hintergrund, ich hab sowas nicht im Studium gehabt. am effektivsten wäre es beim richtigen Assistenten anzurufen.
Tschau
rolf
Hi
werden, kommen da bestimmt so um die 100.000 Worte zusammen. Alle komprimiert (32Bit reicht da völlig) ...
Interessehalber, wie stellst du dir diese Kompression der Wörter vor? Huffmancodes wohl kaum - der Länge wegen - oder?
Tschau
rolf
你好 LanX!,
mehr Platz als die Schroeplsche Volltextdatei???
Ist doch auf voellig logisch. Es fallen viel mehr Metadaten an.
Ähm, eigentlich nicht wenn man zweistufig arbeitet...Ihr habt aber
wohl ein anderes Konzept.
Ich weiss nicht, was du mit zweistufig meinst, aber ein Stichwort-Index
in einer Datenbank braucht zwangslaeufig mehr Platz als ein simpler
Volltext-Index in Dateien. Die Metadaten, von denen ich sprach, braucht
die Datenbank, um die Daten verwalten zu koennen.
Was sind hier Metadaten?
Feldgroessen, Pointer zu dem naechsten Eintrag, etc, pp.
Speichert ihr zu jedem _Wort_ Autor, Datum, Link, etc als Strings ab?
Es reicht doch eine Referenz aufs Postinginfos in einer Tabelle
abzulegen, soviel Zeit kostet das doch wohl nicht.
Nein, aber 4 Byte (willkuerlich) bei jedem Stichwort mehr als bei Dateien
mit pro Zeile einen Datensatz ;-)
Ich hab jetzt keine Zeit es durchzurechnen (Party ruft) aber ich
fürchte ihr arbeitet etwas uneffektiv.
Du darfst dich beruhigen, Daniela weiss schon, was sie tut.
Versucht Michaels Script eigentlich den Vollindex im Speicher zu
halten, und wenn ja wieviel RAM hat der Server?
Natuerlich nicht, *krkr*
再见,
CK
Hallo Christian,
Versucht Michaels Script eigentlich den Vollindex im Speicher zu
halten, und wenn ja wieviel RAM hat der Server?Natuerlich nicht, *krkr*
Warum nicht? Wenn ich die Größen-Angaben der SelfSuche zusammenzähle
komme ich auf 673MB, die kriegt man in 2GB Ram doch locker unter?
Gruß
Alexander Brock
你好 Alexander,
Versucht Michaels Script eigentlich den Vollindex im Speicher zu
halten, und wenn ja wieviel RAM hat der Server?Natuerlich nicht, *krkr*
Warum nicht? Wenn ich die Größen-Angaben der SelfSuche zusammenzähle
komme ich auf 673MB, die kriegt man in 2GB Ram doch locker unter?
Weil der RAM fuer die Datenbank reserviert ist.
再见,
CK
Hi CK,
Weil der RAM fuer die Datenbank reserviert ist.
Erfüllt die DB eigentlich noch eine andere Aufgabe als die Suche zu unterstützen?
tschau
rolf
Hi Rolf
Erfüllt die DB eigentlich noch eine andere Aufgabe als die Suche zu unterstützen?
Ja. Die ganze Benutzerauthentifikation fürs Forum läuft beispielsweise darüber.
Gruss Daniela
Frohes neues Christian,
Ich weiss nicht, was du mit zweistufig meinst,
siehe https://forum.selfhtml.org/?t=97702&m=595113, ihr realisiert glaube ich eh nur die erste Stufe, die Stichwortsuche (was 95% der Anfragen abdecken sollte).
Z.B. Phrasensuche könnte erst in der 2 Stufe realisiert werden.
aber ein Stichwort-Index in einer Datenbank braucht zwangslaeufig mehr Platz als ein simpler Volltext-Index in Dateien. Die Metadaten, von denen ich sprach, braucht die Datenbank, um die Daten verwalten zu koennen.
Was sind hier Metadaten?
Feldgroessen, Pointer zu dem naechsten Eintrag, etc, pp.
OK dann hab ich Metadaten missverstanden, instinktiv geschätzt dürfte der Overhead aber höchstens linear sein, doppelter Platzbedarf?
Speichert ihr zu jedem _Wort_ Autor, Datum, Link, etc als Strings ab?
Es reicht doch eine Referenz aufs Postinginfos in einer Tabelle
abzulegen, soviel Zeit kostet das doch wohl nicht.Nein, aber 4 Byte (willkuerlich) bei jedem Stichwort mehr als bei Dateien
mit pro Zeile einen Datensatz ;-)
Ich bin davon ausgegangen dass ihr analog zu Textzeilen pro Stichwort ein Array mit Referenzen zu Postings ablegt. Wie vorgerechnet käme eine _Datei_ mit Stichwortindex mit deutlich weniger aus. Insbesondere wenn durch Einsatz eines Stoppwortfilters die Anzahl der Stichwörter reduziert wird.
Versucht Michaels Script eigentlich den Vollindex im Speicher zu
halten, und wenn ja wieviel RAM hat der Server?Natuerlich nicht, *krkr*
Meinst du nicht der skizzierte Stichwortindex als Hasharray realisiert würde es können, und würde auch von der Performace mithalten?
Der Ansatz ist wohl mit einer DB eine bewährte und wartungsarme Technologie einzusetzen, deren Overhead mit Hardware kompensiert werden kann. Bleibt die Hoffnung dass das Archiv jetzt nicht schneller wächst als Moores Gesetz :)
Bye
Rolf
Hi Rolf
Z.B. Phrasensuche könnte erst in der 2 Stufe realisiert werden.
Erst Sourcen ansehen, dann meckern. Das wird genau so gemacht in der neuen Suche.
Ich bin davon ausgegangen dass ihr analog zu Textzeilen pro Stichwort ein Array mit Referenzen zu Postings ablegt.
Nein, das würde einen zusätzlichen Join bedeuten, zudem müsste eine Referenz bei uns wohl 8 Byte gross sein. Es bedeutet also speicherplatzmässig kaum Gewinn.
Wie vorgerechnet käme eine _Datei_ mit Stichwortindex mit deutlich weniger aus. Insbesondere wenn durch Einsatz eines Stoppwortfilters die Anzahl der Stichwörter reduziert wird.
Ein Stoppwortfilter wird ebenfalls eingesetzt.
Meinst du nicht der skizzierte Stichwortindex als Hasharray realisiert würde es können, und würde auch von der Performace mithalten?
Ein Hasharray kann erst recht nicht zwischen Gross- und Kleinschreibung unterscheiden. Dazu kommt noch, das eine Hashtabelle um effizient zu sein eigentlich komplett im Speicher gehalten werden muss.
Der Ansatz ist wohl mit einer DB eine bewährte und wartungsarme Technologie einzusetzen, deren Overhead mit Hardware kompensiert werden kann.
Jein, ohne Suchbäume kommt man kaum aus, ebenso nicht wirklich um Joins. Beides hat eine Datenbank bereits zuverlässig und auch zügig implementiert. Der Overhead ist also nicht so gross wie zu erwarten wäre. Bei einem Eigenbau mit begrenzter Entwicklerkapazität wäre das ziemlich schwierig ähnlich gut oder sogar besser hinzukriegen.
Gruss Daniela
Hi Daniela
Erst Sourcen ansehen, dann meckern.
Ich meckerte nicht, ich interpretierte nur folgendes von Christian:
Ich weiss nicht, was du mit zweistufig meinst,
Das wird genau so gemacht in der neuen Suche.
Aha, läuft Stufe 2 direkt auf den Archivdateien oder auch in der DB?
Ich bin davon ausgegangen dass ihr analog zu Textzeilen pro Stichwort ein Array mit Referenzen zu Postings ablegt.
Nein, das würde einen zusätzlichen Join bedeuten, zudem müsste eine Referenz bei uns wohl 8 Byte gross sein. Es bedeutet also speicherplatzmässig kaum Gewinn.
verstehe ich nicht, verstehe wohl auch zu wenig von DBs ...
Du legst also lauter Paare (wort,posting) ab???
Ein Hasharray kann erst recht nicht zwischen Gross- und Kleinschreibung unterscheiden.
Deswegen ja Stichwörter nur in klein und casesensitiv in der 2. Stufe abklären. (hei ich soll deine sourcen lesen und du ließt nicht meine Postings? ;)
Dazu kommt noch, das eine Hashtabelle um effizient zu sein eigentlich komplett im Speicher gehalten werden muss.
IMHO machbar.
Tschau
Rolf
PS: Kann man das Konzept (nicht die sourcen) irgendwo nachlesen,
... zum schlauer werden nicht zum meckern.
Hi Rolf
Das wird genau so gemacht in der neuen Suche.
Aha, läuft Stufe 2 direkt auf den Archivdateien oder auch in der DB?
Weder noch.
Nein, das würde einen zusätzlichen Join bedeuten, zudem müsste eine Referenz bei uns wohl 8 Byte gross sein. Es bedeutet also speicherplatzmässig kaum Gewinn.
verstehe ich nicht, verstehe wohl auch zu wenig von DBs ...
Du willst eine Matrix aus Schlüsselwörtern und Postings aufbauen. Das bedeutet 3 Tabellen, eine mit den Schlüsselwörtern, eine mit den Postings und eine die verlinkt. Wir haben aber sehr viele Postings und sehr viele Schlüsselwörter, das bedeutet auch entsprechend grosse IDs um die beiden zu verlinken. Nehmen wir jetzt doch mal 4 Byte grosse IDs wobei ich denke das es eng werden könnte. Du hast jetzt 4 Byte in der Schlüsselworttabelle und nochmal 2 * 4 in der für die Postings. Macht allermindestens 8 Byte pro Zelle in deiner Matrix. Zusätzlich noch jeweils die erste Spalte und die erste Zeile mit den Postings resp den Schlüsselwörtern drin.
Du legst also lauter Paare (wort,posting) ab???
Paare ja, aber (wort, link auf posting). 8 Byte würden nur für Links draufgehen, sicherheitshalber bei grösseren IDs 16, das wären 8 resp 16 Buchstaben. Das ist nicht wirklich viel unter der durchschnittlichen Wortlänge. Dafür dann noch einen zusätzlichen Join... Ich denke nicht dass das ein guter Tausch wäre die ID zu benutzen anstelle dem Wort direkt.
Ein Hasharray kann erst recht nicht zwischen Gross- und Kleinschreibung unterscheiden.
Deswegen ja Stichwörter nur in klein und casesensitiv in der 2. Stufe abklären. (hei ich soll deine sourcen lesen und du ließt nicht meine Postings? ;)
Damit sparst du zwar Speicherplatz in deiner Version mit Links, nicht aber wenn du direkt das Wort benutzt. Die zweite Stufe der Suche hinzuschalten ist aber sehr teuer, vorallem da du die Datenbank auch einfach einen zusätzlichen Index auf UPPER(wort) legen lassen könntest. Ok, das braucht wieder Speicherplatz.
Dazu kommt noch, das eine Hashtabelle um effizient zu sein eigentlich komplett im Speicher gehalten werden muss.
IMHO machbar.
IMHO unmöglich. In der Hashtabelle brauchst du alle Worte. Mein Duden hat 120000 Worte drin, nehmen wir mal an, so viele Worte haben wir auch (wir haben ja auch noch falsch geschriebene Worte, Dialekte und Fremdsprachige). Dazu müssten es den MessageIDs nach fast 600000 Postings sein, nehmen wir mal an 500000, ID-Grösse 4 Byte. Nehmen wir weiter an, das Durchschnittsposting hat 25 Wörter was auch sehr wenig ist. Wir benutzen 4 Byte Hashwerte. Damit hätten wir, unbesetzte und Doubletten und sowas ausgenommen: 500K Postings * 4 Byte für die ID * durchschnittlich 30 Worte * 4 Byte für deren ID ~= 230 MB. All das sind sehr sehr klein geschätzte Werte, überläufe und nicht gefüllte Hashwerte kommen da auch noch dazu. Ebenso dazu kommt noch Selfhtml, Featureartikel und einiges andere. Dann noch weitere, wenn auch viel kleinerer Index für die ganzen Fremdsprachen... Dazu auch noch entweder die Volltextindizes oder die Postings direkt die während dem Verarbeiten auch im Ram gehalten werden wollen
PS: Kann man das Konzept (nicht die sourcen) irgendwo nachlesen,
... zum schlauer werden nicht zum meckern.
Aktuell gibt es nichts öffentlich verlinktes, nein. Ich werde es die Tage mal nachholen, kann aber noch dauern.
Gruss Daniela
Hi Daniela
Das wird genau so gemacht in der neuen Suche.
Aha, läuft Stufe 2 direkt auf den Archivdateien oder auch in der DB?
Weder noch.
Sondern? Ein äquivalent zu Michaels Vollindex? Muss dafür sowieso ein Plattenzugriff erfolgen?
Tschau
Rolf
Hi Rolf
Sondern? Ein äquivalent zu Michaels Vollindex? Muss dafür sowieso ein Plattenzugriff erfolgen?
Ja. Nur muss ich da nicht pro Thread eine Datei öffnen sondern kann eine pro Index öffnen und dann direkt mit fseek zu den jeweiligen Einträgen springen. Ausserdem brauch ich die nur für die Phrasensuche.
Gruss Daniela
Hallo Daniela,
ich hab jetzt die Ruhe mitzurechnen ...
Nein, das würde einen zusätzlichen Join bedeuten, zudem müsste eine Referenz bei uns wohl 8 Byte gross sein. Es bedeutet also speicherplatzmässig kaum Gewinn.
verstehe ich nicht, verstehe wohl auch zu wenig von DBs ...
Du willst eine Matrix aus Schlüsselwörtern und Postings aufbauen. Das bedeutet 3 Tabellen, eine mit den Schlüsselwörtern, eine mit den Postings und eine die verlinkt.
verstehe wohl auch zu wenig von DBs, eine verlinkende Struktur der Form
Schlüsselwort -> (*posting1, *posting2, *posting3, ...)
wäre m.E. speichereffizient und ausreichend.
Wir haben aber sehr viele Postings und sehr viele Schlüsselwörter, das bedeutet auch entsprechend grosse IDs um die beiden zu verlinken. Nehmen wir jetzt doch mal 4 Byte grosse IDs wobei ich denke das es eng werden könnte. Du hast jetzt 4 Byte in der Schlüsselworttabelle und nochmal 2 * 4 in der für die Postings. Macht allermindestens 8 Byte pro Zelle in deiner Matrix.
Zusätzlich noch jeweils die erste Spalte und die erste Zeile mit den Postings resp den Schlüsselwörtern drin.
In der Betrachtung kann man IMHO diese ruhig Unterschlagen (linear statt quadratisch).
Du legst also lauter Paare (wort,posting) ab???
Paare ja, aber (wort, link auf posting). 8 Byte würden nur für Links draufgehen, sicherheitshalber bei grösseren IDs 16, das wären 8 resp 16 Buchstaben.
verstehe ich nicht, aktuell reichen 32bit locker aus um die Postings (zumindest eines Jahres) zu nummerieren.
Das ist nicht wirklich viel unter der durchschnittlichen Wortlänge. Dafür dann noch einen zusätzlichen Join... Ich denke nicht dass das ein guter Tausch wäre die ID zu benutzen anstelle dem Wort direkt.
Ein Hasharray kann erst recht nicht zwischen Gross- und Kleinschreibung unterscheiden.
Deswegen ja Stichwörter nur in klein und casesensitiv in der 2. Stufe abklären. (hei ich soll deine sourcen lesen und du ließt nicht meine Postings? ;)
Damit sparst du zwar Speicherplatz in deiner Version mit Links, nicht aber wenn du direkt das Wort benutzt. Die zweite Stufe der Suche hinzuschalten ist aber sehr teuer, vorallem da du die Datenbank auch einfach einen zusätzlichen Index auf UPPER(wort) legen lassen könntest. Ok, das braucht wieder Speicherplatz.
Natürlich ist die 2 Stufe teuer, die Frage ist wie man am effizientesten die 2 Stufe abkürzt. Effizient hieße dabei am besten i m Schritt 1 nur im RAM zu suchen und möglichst wenig unötige Treffer in der 2. Stufe zu haben.
Ich gehe von der Annahme aus das:
1. Die allermeisten sowieso kaum casesensitive suchen.
2. Die meisten eine ausführliche Anzeige wollen, also sowieso auf die Platte zugegriffen wird.
3. Zuviele Leute in den Posts eine unsaubere Klein/Großschreibung haben.
Also lieber die Anzahl der Schlüsselwörter halbieren um damit möglichst viele ins RAM zu bekommen.
Das zurückführen eines Wortes auf seine lower()-Variante kann man übrigens auch als primitive und effiziente Hashfunktion interpretieren.
Dazu kommt noch, das eine Hashtabelle um effizient zu sein eigentlich komplett im Speicher gehalten werden muss.
IMHO machbar.
IMHO unmöglich. In der Hashtabelle brauchst du alle Worte. Mein Duden hat 120000 Worte drin, nehmen wir mal an, so viele Worte haben wir auch (wir haben ja auch noch falsch geschriebene Worte, Dialekte und Fremdsprachige).
Das ist korrekt, auch stehen viele Wörter nicht im Duden. Es macht aber keinen Sinn jede Buchstabenkombination gleich zu behandeln, da auch viele Verschreiber auftauchen. Man optimiert doch auf den Normalfall und nicht auf den Worst-Case, den Aufwand des letzteren sollte man nur vernünftig beschränken, damit die Algo nicht im Nirwana verschwindet.
Mal ein pragmatischer Ansatz:
Das normale Vokabular eines Menschen liegt selten über 60000 Wörter,
wenn wir die häufigsten 65536 Wörter des Archivs (ohne Stoppwörter) in einen optimierten² RAM-Hash legen, wäre das bereits sehr effizient und würde auch bereits mit "normaler" Hardware funktionieren.
Nur in dem Fall, dass eine Dublette eines selteneren Wortes vorliegt müßte dann ein Plattenzugriff erfolgen. In den 65536 zugehörigen Files könnten dann die Dubletten wieder organisiert sein (eventuell wieder Hashes oder Binärbaum oder ne simple Liste).
Plattenzugrife müssen in der Suche sowieso erfolgen, die paar mehr die nur im Falle seltener Wörter vorkämen fallen kaum ins Gewicht. Für die Belange der Archivsuche reicht das IMHO allemal, und man ist von Hardwareanbietern unabhängig.
Um diese Datenstruktur dann zu pflegen reicht es dann diese Files upzudaten.
Wenn man _noch_ effizienter arbeiten will, wäre es sinnvoll eine Statistik der am häufigsten gesuchten Wörter zu erstellen und diese zusätzlich im RAM vorzuhalten. (javascript, frame, ...)
Wo ich dir recht gebe ist, dass eine DB mir einige Kopfschmerzen über updateintervalle, konsistenz, transaktionssicherheit, usw. erspart.
PS: Kann man das Konzept (nicht die sourcen) irgendwo nachlesen,
... zum schlauer werden nicht zum meckern.Aktuell gibt es nichts öffentlich verlinktes, nein. Ich werde es die Tage mal nachholen, kann aber noch dauern.
Lass dir wegen mir ruhig Zeit, ich will nur meine DB Dummheit veruntiefen...
Tschau
rolf
²wobei ich nicht weiß wie Laufzeiteffektiv diese optimalen Hashes sind. Für die Bedürfnisse des Forums wären auch Hashfkten interessant die typische Tippfehler glätten. Neben der Großschreibung machen weggefallene und verdrehte Buchstaben (also Buhcstaben) das Gros aus.
Wenn also "simpel", "Simple", "simple", "simpl" auf den gleichen Hashwert abgebildet werden, wär das sogar ein Vorteil. Filtern könnte man noch sehr effizient im 2. Schritt und könnte zusätzlich noch eine Ähnlichkeitssuche wie bei google anbieten ("meinten sie etwa ...")
Habe so eine Fkt schon irgendwo gesehen, beruhte AFAIK darauf dass jeder Buchstabe mit seinem Vorgänger (und Nachfolger?) addiert wurde, oder so. Das würde auch zu dem Ansatz passen die Häufigkeit von Bi- und Trigrammen (2er und 3er Buchstabengruppen) im Archiv³ heranzuziehen, um einen möglichst gut balancierten Hash zu basteln.
Die Königsfrage bleibt dann: Wie suche ich effektiv Teilstrings in den Schlüsselwörtern? Denn viele Leute werden leider nicht die Option "eigenständige Worte[*]" aktivieren.
³wohlgemerkt nicht im Duden, weil wir hier sowieso eine eigene Subsprache haben.
³ ähm ich bin selbst kein Held der Rechtschreibung und diesbezüglich sehr liberal/ignorant, aber sollte das nicht "Begriffe als eigenständige _Wörter_ suchen" heißen? "Worte" sind sowas ähnliches wie Phrasen und Gedanken ("die Worte des großen Vorsitzenden" ...)und bestehen aus Wörtern.
Hi Rolf
Schlüsselwort -> (*posting1, *posting2, *posting3, ...)
wäre m.E. speichereffizient und ausreichend.
Die Literatur zur 1. Normalform erklärt dir hinreichend, warum man sowas _niemals_ tun sollte. Allgemein würde ich auch sonst Datenbankliteratur empfehlen, auch zum Thema Joins. Achja, Datenbanken cachen durchaus auch. Wenn gewisse Dinge oft gebraucht werden, liegen sie also sowieso im Ram.
Zusätzlich noch jeweils die erste Spalte und die erste Zeile mit den Postings resp den Schlüsselwörtern drin.
In der Betrachtung kann man IMHO diese ruhig Unterschlagen (linear statt quadratisch).
Ehm, nein, kann man nicht, ich würde durchaus mit einigen Megabytes mehr rechnen.
verstehe ich nicht, aktuell reichen 32bit locker aus um die Postings (zumindest eines Jahres) zu nummerieren.
Wir haben aber nicht nur die Postings. Zudem nimmt die Zahl der Postings aktuell nicht linear zu sondern eher in Richtung exponentiell.
- Die meisten eine ausführliche Anzeige wollen, also sowieso auf die Platte zugegriffen wird.
Nein, diese Information ist direkt in der Datenbank verfügbar.
Das zurückführen eines Wortes auf seine lower()-Variante kann man übrigens auch als primitive und effiziente Hashfunktion interpretieren.
Aha? Mir wäre neu das dabei eine Zahl herauskommt, die entweder einen Index in einem Array darstellt oder aber direkt eine Speicheradresse.
wenn wir die häufigsten 65536 Wörter des Archivs (ohne Stoppwörter) in einen optimierten² RAM-Hash legen, wäre das bereits sehr effizient und würde auch bereits mit "normaler" Hardware funktionieren.
Gerade nach den häufigsten Wörtern zu suchen, ist aber nicht sinnvoll. Möglichst gute Treffer erzielt man mit spezifischen Suchwörtern.
Nur in dem Fall, dass eine Dublette eines selteneren Wortes vorliegt müßte dann ein Plattenzugriff erfolgen. In den 65536 zugehörigen Files könnten dann die Dubletten wieder organisiert sein (eventuell wieder Hashes oder Binärbaum oder ne simple Liste).
Wozu zugehörige Files? Du willst aber nicht pro Wort in dem Hash einfach auf ein File verweisen wo eine Liste aus den möglichen Postings drin steht? Dazu brauche ich keinen Hash, dazu reichen Namenskonventionen.
Plattenzugrife müssen in der Suche sowieso erfolgen, die paar mehr die nur im Falle seltener Wörter vorkämen fallen kaum ins Gewicht. Für die Belange der Archivsuche reicht das IMHO allemal, und man ist von Hardwareanbietern unabhängig.
Erklär doch mal das Konzept was du da machen willst. Was ich mir aktuell darunter vorstelle, klingt sehr sehr langsam und unsinnig, deswegen denke ich, dass da doch das eine oder andere Missverständnis liegt.
Gruss Daniela
Hallo Daniela
Allgemein würde ich auch sonst Datenbankliteratur empfehlen, auch zum Thema Joins.
Da hast du sicher recht.
Ehm, nein, kann man nicht, ich würde durchaus mit einigen Megabytes mehr rechnen.
Sicher aber im Verhältnis zum quadratischen Speicheraufwand einiger zig Megabytes der Matrixwerte selbst eher zweitrangig, oder?
Wir haben aber nicht nur die Postings. Zudem nimmt die Zahl der Postings aktuell nicht linear zu sondern eher in Richtung exponentiell.
Das spräche dann aber gegen eine Lösung die so hohe Hardwareerfordernisse hat wie deine, da ansonsten die Platten künftig nicht schnell genug mitwachsen, oder?
- Die meisten eine ausführliche Anzeige wollen, also sowieso auf die Platte zugegriffen wird.
Nein, diese Information ist direkt in der Datenbank verfügbar.
Du hinterlegst die ersten 500 bytes jedes Postings in der DB?
Das sind unkomprimiert 300MB Daten, lohnt sich das?
Das zurückführen eines Wortes auf seine lower()-Variante kann man übrigens auch als primitive und effiziente Hashfunktion interpretieren.
Aha? Mir wäre neu das dabei eine Zahl herauskommt, die entweder einen Index in einem Array darstellt oder aber direkt eine Speicheradresse.
"Hash-Funktion
aus Wikipedia, der freien Wissensdatenbank
Eine Hash-Funktion (von en. "to hash": zerhacken, dt. Bezeichnung: Streuwertfunktion) ist eine nicht umkehrbare Funktion (ein Algorithmus), die eine umfangreiche Quellmenge (i.d.R. Texte) auf eine wesentlich kleinere Zielmenge (Hash-Werte, i.d.R. natürliche Zahlen und Buchstaben) abbildet."
lower() bildet die umfangreichere Menge der Wörter aus [a-zA-Z] auf Wörter aus [a-z] ab. Kollisionen entstünden z.B. bei den Wörtern "Sein" und "sein", und würden in unserem Fall im 2.Schritt aufgelöst.
wenn wir die häufigsten 65536 Wörter des Archivs (ohne Stoppwörter) in einen optimierten² RAM-Hash legen, wäre das bereits sehr effizient und würde auch bereits mit "normaler" Hardware funktionieren.
Gerade nach den häufigsten Wörtern zu suchen, ist aber nicht sinnvoll. Möglichst gute Treffer erzielt man mit spezifischen Suchwörtern.
Da hast du wiederum recht, für eine Optimierung wären also die häufigsten Suchbegriffe besser geeignet.
Nur in dem Fall, dass eine Dublette eines selteneren Wortes vorliegt müßte dann ein Plattenzugriff erfolgen. In den 65536 zugehörigen Files könnten dann die Dubletten wieder organisiert sein (eventuell wieder Hashes oder Binärbaum oder ne simple Liste).
Wozu zugehörige Files? Du willst aber nicht pro Wort in dem Hash einfach auf ein File verweisen wo eine Liste aus den möglichen Postings drin steht? Dazu brauche ich keinen Hash, dazu reichen Namenskonventionen.
Nein, du meinst wenn man "Javascript" sucht greift man auf das File "Javascript" zu. Das wäre eine Selbstlüge weil man die Suche nach der Datei "Javascript" auf das Betriebssystem/Festplattencontroller abwälzt. Die Hashtabelle liefert stattdesen direkt das Handle der Datei.
Erklär doch mal das Konzept was du da machen willst. Was ich mir aktuell darunter vorstelle, klingt sehr sehr langsam und unsinnig, deswegen denke ich, dass da doch das eine oder andere Missverständnis liegt.
Man nimmt offenes Hashing wie in http://de.wikipedia.org/wiki/Hash-Funktion#Offenes_Hashing definiert, d.h. als Hashwert wird eine Datenstruktur möglicher Schlüssel abgelegt. Diese Datenstruktur kann sowohl Schlüssel/Werte Paare enthalten als auch die Referenz auf eine Datei mit weiteren ausgelagerten Schlüssel/Werte Paaren.
Die Hashfkt ist auf die häufigsten Suchbegriffe hin optimiert, deren Werte weitestmöglich im RAM gehalten werden (je nach Ausbau). Filezugriffe auf ausgelagerte Schlüsselwörter werden so minimiert.
Ein Werte ist dabei eine Liste von Referenzen auf Postings, wird nach mehreren Schlüsselwörtern gesucht, duchsucht man im 2.Schritt nur die Schnittmenge dieser Listen.
Tschau
Rolf
PS: Weißt du mit welchem Aufwand eine Teilwortsuche in der DB läuft?
Hi Rolf
Allgemein würde ich auch sonst Datenbankliteratur empfehlen, auch zum Thema Joins.
Da hast du sicher recht.
Ich würde dir echt wenigstens die Normalformen empfehlen, auch wenn du eher Dateien magst zeigen sie dir mögliche Probleme auf.
Sicher aber im Verhältnis zum quadratischen Speicheraufwand einiger zig Megabytes der Matrixwerte selbst eher zweitrangig, oder?
Trotzdem trägt es dazu bei, das auch da die Hardware aufgerüstet werden müsste.
Das spräche dann aber gegen eine Lösung die so hohe Hardwareerfordernisse hat wie deine, da ansonsten die Platten künftig nicht schnell genug mitwachsen, oder?
Aktuell bräuchte die Datenbank 8GB, nochmal etwa soviel wäre temporär für den Sortiervorgang nötig. Ich denke nicht, dass das hohe Anforderungen sind. Ram ist da wesentlich teurer und gibt es auch nicht in solchen Mengen. Zumal dein Lösungsansatz ja zusätzlich auch noch massig HD verbrauchen würde·
Du hinterlegst die ersten 500 bytes jedes Postings in der DB?
Das sind unkomprimiert 300MB Daten, lohnt sich das?
Imho ja. Dadurch verhindert man, eine Datei öffnen zu müssen und an die entsprechende Stelle springen zu müssen. Beides ist sehr teuer.
Eine Hash-Funktion (von en. "to hash": zerhacken, dt. Bezeichnung: Streuwertfunktion) ist eine nicht umkehrbare Funktion (ein Algorithmus), die eine umfangreiche Quellmenge (i.d.R. Texte) auf eine wesentlich kleinere Zielmenge (Hash-Werte, i.d.R. natürliche Zahlen und Buchstaben) abbildet."
Nicht jede Hash-Funktion ist für eine Hashtable nutzbar.
lower() bildet die umfangreichere Menge der Wörter aus [a-zA-Z] auf Wörter aus [a-z] ab. Kollisionen entstünden z.B. bei den Wörtern "Sein" und "sein", und würden in unserem Fall im 2.Schritt aufgelöst.
Das ist nach wie vor keine Hashfunktion wie sie bei einer Hashtabelle irgendwie brauchbar wäre...
Nein, du meinst wenn man "Javascript" sucht greift man auf das File "Javascript" zu. Das wäre eine Selbstlüge weil man die Suche nach der Datei "Javascript" auf das Betriebssystem/Festplattencontroller abwälzt. Die Hashtabelle liefert stattdesen direkt das Handle der Datei.
Autsch, du willst die Datei also dauerhaft geöffnet halten?
Man nimmt offenes Hashing wie in http://de.wikipedia.org/wiki/Hash-Funktion#Offenes_Hashing definiert, d.h. als Hashwert wird eine Datenstruktur möglicher Schlüssel abgelegt. Diese Datenstruktur kann sowohl Schlüssel/Werte Paare enthalten als auch die Referenz auf eine Datei mit weiteren ausgelagerten Schlüssel/Werte Paaren.
Viel Spass, ich hab dir ja vorgerechnet, wie gross das dann wird...
Ein Werte ist dabei eine Liste von Referenzen auf Postings, wird nach mehreren Schlüsselwörtern gesucht, duchsucht man im 2.Schritt nur die Schnittmenge dieser Listen.
Die zu bilden ist übrigens auch sehr witzig...
PS: Weißt du mit welchem Aufwand eine Teilwortsuche in der DB läuft?
Kommt drauf an ob der Anfang oder das Ende fehlt. Wenn der Anfang fehlt wird der Aufwand ohne weitere Massnahmen linear. Allerdings benutzt die neue Suche Massnahmen die das verhindern. Da läuft es dann einmal logarithmisch um alle möglichen Ganzwörter zu finden, dann nochmal logarithmisch pro möglichem Ganzwort um an die Postings zu kommen.
Gruss Daniela
Hi Daniela
Zumal dein Lösungsansatz ja zusätzlich auch noch massig HD verbrauchen würde·
Nö wieso, ich habe bereits vorgerechnet dass es IMHO deutlich dichter ist als alles bisherige. https://forum.selfhtml.org/?t=97702&m=595156 oder https://forum.selfhtml.org/?t=97702&m=595277
(deine (großzügigere) Rechnung lieferte 230MB gegenüber 8GB DB-Volumen) Pro Matrixwert fällt nur die Referenz aufs Posting an. 4 Bytes pro Referenz sind da für mich das Maximum, insbesondere weil man's ohne große Performanceverluste weiter eindampfen könnte.
Du hinterlegst die ersten 500 bytes jedes Postings in der DB?
Das sind unkomprimiert 300MB Daten, lohnt sich das?Imho ja. Dadurch verhindert man, eine Datei öffnen zu müssen und an die entsprechende Stelle springen zu müssen. Beides ist sehr teuer.
Eine Hash-Funktion (von en. "to hash": zerhacken, dt. Bezeichnung: Streuwertfunktion) ist eine nicht umkehrbare Funktion (ein Algorithmus), die eine umfangreiche Quellmenge (i.d.R. Texte) auf eine wesentlich kleinere Zielmenge (Hash-Werte, i.d.R. natürliche Zahlen und Buchstaben) abbildet."
Nicht jede Hash-Funktion ist für eine Hashtable nutzbar.
Ich sagte "Das zurückführen eines Wortes auf seine lower()-Variante kann man übrigens auch als primitive und effiziente Hashfunktion interpretieren"
Der Wert einer Hashfunktion ist nicht notwendigerweise ein Pointer in ein Array, hier wird die lower-Variante als Key einer kleineren Suchtabelle genutzt, und später die Kollision aufgelöst.
Nichts anderes machst du übrigens, wenn du statt ganzer Phrasen nur die Einzelwörter suchst, und die Kollisionen
(Einzelwörter in falscher Reihenfolge) später wegwirfst.
Das Prinzip ist das gleiche.
Das ist nach wie vor keine Hashfunktion wie sie bei einer Hashtabelle irgendwie brauchbar wäre...
wie gesagt "primitive Hashtabelle".
Autsch, du willst die Datei also dauerhaft geöffnet halten?
Was die performanteste Lösung fürs Filesystem ist weiß ich nicht, da die DB sowieso einen _noch_ größeren Teil seiner Daten ebenfalls ausgelagert hat, kann man entweder mit einer vergleichbaren Zugriffstechnik arbeiten oder -falls es sich rechnet- dafür eine DB nutzen.
Viel Spass, ich hab dir ja vorgerechnet, wie gross das dann wird...
Wie gesagt, es kann nicht größer werden als Michaels Vollindex oder deine DB, eher deutlich kleiner, selbst wenn alle Hashes halb besetzt sind. Und nur was ins RAM passt, soll da auch rein.
Ein Werte ist dabei eine Liste von Referenzen auf Postings, wird nach mehreren Schlüsselwörtern gesucht, duchsucht man im 2.Schritt nur die Schnittmenge dieser Listen.
Die zu bilden ist übrigens auch sehr witzig...
och - erster Ansatz - aufsteigendes vorsortieren aller Postingreferenzen sollte locker reichen. (Dann kann man auch mit Differenzen arbeiten um die Datendichte zu erhöhen²) Falls das zu langsam wäre könnte man sicher genug Literatur zum Thema finden.
Gruss
Rolf
²bei 600000 Postings aktuell, würde es reichen dass ein Wort mehr als 10 mal "regelmäßig" auftaucht, damit man den Abstand zum nächsten "Treffer" mit 2 Bytes kodieren könnte. Also gerade große Listen ließen sich sehr gut eindampfen.
Hi,
mehr Platz als die Schroeplsche Volltextdatei???
Ist doch auf voellig logisch. Es fallen viel mehr Metadaten an.
ich vermute mal, dass die "Schroepelsche Volltextdatei" die Archivdatenhaltung bezeichnet, d.h. ein Haufen von XML-Dateien beispielsweise?
Ähm, eigentlich nicht wenn man zweistufig arbeitet...Ihr habt aber
wohl ein anderes Konzept.Ich weiss nicht, was du mit zweistufig meinst, aber ein Stichwort-Index
in einer Datenbank braucht zwangslaeufig mehr Platz als ein simpler
Volltext-Index in Dateien. Die Metadaten, von denen ich sprach, braucht
die Datenbank, um die Daten verwalten zu koennen.
Nun, falls hier die Aussage versucht wird, dass Metadaten (Indexdaten) mengenmaessig immer groesser sind oder sein muessen als die eigentlichen Daten, dann ist das schon etwas falsch.
Und was ist denn hier mit "Volltext-Index" gemeint? (Die Archivsuche findet doch auch Zeichenketten beliebiger Art, die sicherlich nicht fuer Suchzwecke indiziert worden sind. Es gibt also tatsaechlich eine "just-in-time Suche".)
Gruss,
Ludger
Hi Ludger
ich vermute mal, dass die "Schroepelsche Volltextdatei" die Archivdatenhaltung bezeichnet, d.h. ein Haufen von XML-Dateien beispielsweise?
Nein, es meint die Schoepelschen Volltextdateien.
Nun, falls hier die Aussage versucht wird, dass Metadaten (Indexdaten) mengenmaessig immer groesser sind oder sein muessen als die eigentlichen Daten, dann ist das schon etwas falsch.
Nein, die Aussage ist, das Metadaten + Daten immer grösser sind als die Daten alleine.
Und was ist denn hier mit "Volltext-Index" gemeint? (Die Archivsuche findet doch auch Zeichenketten beliebiger Art, die sicherlich nicht fuer Suchzwecke indiziert worden sind. Es gibt also tatsaechlich eine "just-in-time Suche".)
Nein, gibt es nicht.
Gruss Daniela
Eine case-insensitive Suche ist nun mal aufwendiger.
... für den Nutzer, weil er das Häkchen ändern muss.
Da auch einige Stammposter sich konsequent der Groß- und Kleinschreibung verweigern, macht case-sensitive Suche wirklich nicht viel Sinn (für den Nutzer).
Gunnar
Wenn Du Touchpads haßt, warum benutzt Du sie dann?
Die Tab-Taste funktioniert, die Leerzeichentaste auch ...
Stimmt. Aber dann müsste ich meine schweren, arthrose-gebeutelten Hände ja unnötigerweise auf / über die Tastatur bewegen. In jedem Fall läuft es auf überflüssige Bewegungen hinaus.
Hm - hier hast Du Verständnis für die "überlastungstechnischen Gründe".
Ja, weil es hier darum geht, riesige Datenbestände in die Suche miteinzubeziehen. Das hier Überlastung eingedämmt werden soll, erklärt sich mir von selbst, aber...
"Groß- bzw. Kleinschreibung berücksichtigen"
Hier hast Du aber kein Verständnis für die "überlastungstechnischen Gründe".
Eine case-insensitive Suche ist nun mal aufwendiger.
...weshalb das in gleichem Maße belastend für die Ressourcen sein soll, kann ich noch nicht ganz nachvollziehen. Die meisten suchen doch zuerst mit aktivierter Groß/Kleinschreibung und danach nochmal case-insensitive. Im schlimmsten Fall also eine Doppelbelastung.
So aufwendig wird doch eine case-insensitive Suche nicht sein, der weit überwiegende Teil der Suchen im Web unterstützt die doch auch.
Michel
Hallo Michel
Wenn Du Touchpads haßt, warum benutzt Du sie dann?
Die Tab-Taste funktioniert, die Leerzeichentaste auch ...Stimmt. Aber dann müsste ich meine schweren, arthrose-gebeutelten Hände ja unnötigerweise auf / über die Tastatur bewegen. In jedem Fall läuft es auf überflüssige Bewegungen hinaus.
Genau umgekehrt wird ein Schuh daraus.
Du gibst den Suchbegriff über die Tastatur ein.
Wenn du jetzt extra das Touchpad benutzt, statt mit der Tab- und Leertaste
deine Einstellungen vorzunehmen, sind das überflüssige Bewegungen.
Nur leider vergessen Benutzer grafischer Oberflächen oft, dass die Tastatur
zu mehr zu gebrauchen ist, als nur dazu Texte zu tippen.
Auf Wiederlesen
Detlef
Hi
mich nervt es immer wieder, dass bei der Archivsuche das Kästchen "Groß- bzw. Kleinschreibung berücksichtigen" standardmäßig aktiviert ist. Kann das mal jemand ausstellen?
mich nervt es immer wieder wenn Leute ihre Energie erst ins Motzen leiten bevor sie das Archiv zu rate ziehen, wobei diese Frage oft genug erörtert wurde. Könntest du dir das mal angewöhnen? ²
der meister hat case-insensitiv mit RegExp realisiert, siehe http://forum.de.selfhtml.org/archiv/2003/1/t33529/#m183440 was die performance drückt. CK hat die Defaults als Workaround geändert, würde der erhoffte Effekt nicht messbar sein, hätte er es kaum beibehalten.
Wenns dich dermaßen nervt schaff dir ein BML mit deinen Defaults. Solche stehen oft genug im Archiv.
Tschau
LanX
²mit der Archivsuche bist du doch vertraut, oder?
