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