Søren in Norwegen

Endlich kann ich ueber diesen Geniestreich reden … aber ich greife vor.

Beim vorletzten Mal „mathematisierte“ ich das Kevin-Bacon-Problem. Das war prinzipiell løsbar, aber ich stellte beim letzten Mal fest, dass es aufgrund von Speicherplatzmangel technisch in der gegebenen Form praktisch nicht løsbar war.

Ich redete beim letzten Mal viel ueber die „Betriebskosten“ (in Form von Speicher) die Datenobjekte haben. Dabei konzentrierte ich mich auf Wortobjekte. Fuer jedes Wort habe ich „Betriebskosten“ von 49 Bytes plus der Speicherbedarf der „Nutzlast“ von 1 Byte pro Buchstabe. Die „Nutzlast“ ist von der Laenge des Wortes abhaengig.

Ich erwaehnte auch, dass eine Zahl keine Laenge hat. Cool ist nun, dass der Gesamtspeicherbedarf („Betriebskosten“ + „Nutzlast“) einer ganzen Zahl auf meinem Rechner unter Python 3.7.3 deutlich kleiner ist als fuer Wørter; naemlich nur 28 Bytes. Und das ist unabhaengig davon, wie grosz die Zahl wird! … Naja, es gibt natuerlich Ausnahmen. Die Null braucht nur 24 Bytes und ganz grosze Zahlen (genauer gesagt ab 1,073,741,824) brauchen dann schon 32 Byte und irgendwann werden die Zahlen so grosz, dass die 36 Byte brauchen usw. Aber das ist hier nicht von Interesse, da ich nicht in diese groszen Bereiche komme mit dem gegebenen Problem.

Und hier kommt jetzt die geniale Idee: Ich bildete jeden Titel auf eine nicht negative ganze Zahl (inklusive der Null) ab. Wenn ein Titel von einem anderen Titel zitiert wird, dann erstatte ich diesen mit der gegebenen Zahl. Die Reihenfolge spielt dabei ueberhaupt keine Rolle. Diese Abbildung ist bijektiv und die Abbildungsvorschrift (einfach eine lange Tabelle welcher Titel welcher Zahl zugeordnet ist) merke ich mir natuerlich, falls ich spaeter eine spezfische Linkkette nachverfolgen will.

Durch die Abbildung auf nicht negative ganze Zahlen verringerte sich der Speicherbedarf meiner 5,798,312 Titel und 165,913,569 Links von ehedem 11 GB auf 4,807,932,668 als ca. 4.8 GB … Huzzah!

Damit habe ich das Kevin-Bacon-Problem nicht nur mathematisiert, sondern auch „verzahlt“. Das coole ist, dass sich dabei der Informationsinhalt, bzgl. der Informationen, an denen ich interessiert war (!), nicht veraenderte. Cool wa!

Zur Veranschaulichung hier das dritte Beispiel vom vorletzten Mal in der neuen Darstellung:

Mit dem Bild erkennt man besser, dass sich der untersuchte Informationsinhalt nicht aendert. Ob Apfel jetzt auf Kuchen zeigt oder 23 auf 5 tut nix zur Sache, solange im gesamten Netzwerk 23 immer mit Apfel und 5 immer mit Kuchen assoziiert ist.

Zum Problem der „Betriebskosten“ der Wortobjekte kamen beim letzen Mal die Betriebskosten der „Waggons“ (oder Ueberstrukturen) in denen diese aufbewahrt wurden. Ein Problem wurde es deshalb, weil jeder Titel einen solchen „Waggon“ hat. Ganz spezifisch waren diese „Waggons“ sogenannte Sets und deren „Betriebskosten“ waren abhaengig von der Anzahl der darin enthaltenen Elemente.
Das Gute ist nun, dass es noch andere Arten von „Waggons“ gibt. Fuer den Verwendungszweck hier ist nur wichtig, dass diese die „Aufbewahrungsbox“ aller zu einem Titel gehørenden Links sind, damit nix durcheinander kommt. Dafuer brauche ich kein Set, wie beim letzten Mal erwaehnt, sondern es reicht ein sogenannten Tupel.
Waehrend man mit Sets urst viel machen kann (bspw. Elemente heraus nehmen oder dazu packen, oder Mengenoperationen mit anderen Sets ausfuehren) kann man mit Tuples (fast) nix machen. Das ist ein unveraenderbarer „Kasten“ fuer meine Links (die ja nun Zahlen sind). Und weil man damit so wenig machen kann, betragen die „Betriebskosten“ eines leeren Tuples nur 56 Bytes und die steigen linear an (diesmal wirklich) mit 8 Byte pro neuem Element.

Wie beim letzten Mal brauche ich nun das Produkt aus der Verteilung der Links pro Titel und dem tatsaechlichen Speicherbedarf der Tuples. Zum Vergleich habe ich in dieses Diagramm das Resultat dieser Rechnung und der gleichen Rechnung vom letzten Mal dargestellt.

So ein Mist, da aendert sich ja nicht viel … ach nee! Die Skala der linken Ordinate ist eine ganze Grøszenordnung (!) kleiner als die Skala der rechten Ordinate … voll krass!

Der Gesamtspeicherbedarf betraegt damit fuer alle „Tuple-Waggons“ keine 11 GB wie bei den Sets, sondern nur 1,605,627,528 Bytes also ca. 1.6 GB.
Da kommen dann noch die ca. 300 MB fuer die oberste Struktur hinzu, welches alle „Waggons“ den richtigen Titeln zuordnen (die „Lokomtive“ vom letzten Mal bzw. das „Dictionary“). Insgesamt benøtige ich mit diesen Modifikationen dann nur noch 6,7 GB.

JIPPIE! So viel Speicher habe ich und deswegen soll das fuer heute reichen. So viel sei nur noch gesagt: hier hingeschrieben hørt sich der Schritt der Abbildung der Titel auf ganze Zahlen voll logisch an. Deswegen war dieser Geniestreich als solcher auch zunaechst unbemerkt. Ich wollte ja erstmal nur das Speicherplatzproblem løsen. Aber letztlich erlaubte mir erst dieser Schritt die (effiziente!) technische Implementierung der Løsung des eigentlichen Problems. Dazu Bedarf es allerdings noch ein paar weiterer (Achtung: Spoiler) „Transformationen“.

Hier …

… bin ich auf Greae Hypa PH-C d1017 2, denn von allen (!) Planeten auf denen man landen kann hat dieser den grøszten Radius mit 28,877.854 km. Das ist natuerlich auch am grøszten fuer diesen Planetentyp — Icy bodies (wo mein Bordcomputer mir erlaubt zur Oberflaeche zu fliegen).

Ein solch riesiger Radius fuehrt (wie gewøhnlich) zu einer hohen Gravitation (aber kein Rekord in diesem Fall) und einer Pfannkuchenoberflaeche … ich meine die Bodenerhebungen und nicht die Farbe … aber die passt hier auch.

Ansonsten fand ich auch noch Ammoniakwelt #182:

Beim letzten Mal beschrieb ich die Umwandlung des urspruenglichen Sprachproblems in ein mathematisches Problem. Damit kann man prinzipiell so wie’s ist (von Apfel zu Kuchen zu Mehl usw.) an die Sache heran gehen.
Wir sprechen hier aber von fast 6 Millionen Knoten (Wikipediatiteln) und mehr als 181-Millionen Verbindungen dazwischen in diesem Netzwerk. Und fuer jeden Knoten muss ich die Gesamtheit der Verbindungen „abschreiten“. Dabei lief ich in ein albekanntes Problem: nicht genug Speicher! Aber der Reihe nach.

Vor ein paar Monden hørte ich mit der Saeuberung der Rohdaten auf und es blieben noch …

[…] 5,798,312 Wikipediaseiten auf denen insgesamt 165,913,569 Links erscheinen […]

… zurueck.

Ich schrieb auch, dass der Speicherbedarf dieser Daten von ehemals ueber 70 GB (die gesamte Wikipedia) auf 4.1 GB verringert wurde. Ich hatte das auf 61 Dateien verteilt und die bin ich fuer die bereits vorgestellten Untersuchungen immer der Reihe nach durchgegangen (denn da hat mich ja das Netzwerk an sich nicht interessiert).
Das Komische war nun, dass das eigentlich alles in den Speicher meines Laptops passen sollte … aber irgendwie kam dieser nicht zurecht, wenn ich versuchte mehr als 10 dieser Dateien gleichzeitig zu laden.

Merkwuerdig … wie sieht das denn eigentlich im Speicher aus?
Nunja, erstmal dachte ich ganz einfach, dass die Titel der Seiten Buchstabenketten (allgemeiner: Zeichenketten) mit einer bestimmten Laenge sind. Dito bzgl. der Links „hinter“ jedem Titel.
Im Wesentlichen braucht ein Buchstabe im Speicher 1 Byte … jaja, Sonderzeichen brauchen mglw. mehr, aber ich sollte davon nicht soooo viele haben … Der Speicherbedarf der Titel sollte also das Integral ueber die hier gezeigte Verteilung sein: 117,194,976 Bytes also ca. 117 MB.
Die Verteilung der Laengen der Links ist sehr aehnlich:

In den nicht normierten Daten ist die Amplitude der Verteilung der Links natuerlich viel grøszer und diese muss natuerlich fuer das Integral genommen werden.
Nebenbemerkung: das kleine „Uebergewicht“ bzw. „Untergewicht“ links bzw. rechts vom Maximum ist sicherlich dadurch zu erklaeren, dass „prominente“ (also oft zitierte) Seiten einen kurzen und knackigen Titel haben — siehe hier. Der Unterschied ist zwar zu sehen, aber nicht so massiv (oder unerwartet), sodass ich mich da nicht weiter fuer interessiere. Insb. auch deswegen nicht, weil die gegebene Erklaerung (mit den Beispielen der meistzitierten Seiten) durchaus plausibel klingt.

Fuer den Speicherbedarf aller in den Links enthaltenen Zeichen errechnete ich nun: 2,898,076,329 also ca. 2.9 GB.

Na sowas! Meine simplen Ueberlegungen løsen die Merkwuerdigkeit nicht auf!
Des Raetsels Løsung ist zweigeteilt und ich gebe zu, dass das ueber das Anfaengerprogrammiererniveau hinaus geht (wenn auch nicht sehr weit). Aber dafuer muss ich etwas ausholen. Das wiederum handelt im vorbeigehen auch gleich etwas ab, was beim naechsten Mal total hilft :) .

Nehmen wir die Zeichenkette „gerader Strich mit kurzer Kappe, zwei mal zwei nach links offene Halbkreise, schraeger Strich mit Vordach“ — oder in kurz 1337.
Ich nehme 1337 mit Absicht. Zum Einen ist es natuerlich die Zahl Eintausenddreihundertsiebenundreiszig. Dann es aber auch das bekannteste Beispiel fuer Leetspeak und wird eben auch direkt als „LEET“ — also ein Wort — interpretiert.
Ein und die selbe (!) Zeichenkette hat also zwei unterschiedliche Bedeutungen. So wir denn von diesen Unterschieden wissen, so ist das fuer uns Menschen i.A. kein Problem 1337 kontextabhaengig richtig zu interpretieren. Wenn ich also sage packe bei 1337 nochmal 1337 ran, so ist das eine Addition im Falle der Zahl und das Ergebnis wird 2274 bzw. wird is im Falle des Wortes 13371337 (also LEETLEET).

Damit bin ich bei einem weiteren wichtigen Aspekt: Operationen.
Abhaengig von der Bedeutung die die Zeichenkette hat, kann man damit unterschiedliche Operationen ausfuehren oder gleiche Operationen, die aber unterschiedliche Ergebnisse haben. Oben erwaehnte ich die Addition. Eine andere Operation waere „Sag mir mal die Laenge von dem was ich gerade vor mir habe“.
Bei LEET entspricht die Laenge natuerlich der Anzahl der Zeichen und ist somit vier. Aber selbst wenn eine Zahl viele Zahlzeichen enthaelt, so ist die Laenge einer Zahl doch immer eins! Das ist besser zu verstehen, wenn man rømische Zahlsymbole nimmt, denn da sind 10, 50, 100, 500 und 1000 nur ein Symbol. Noch cooler ist das cistercianische Zahlsystem, welches bis 9999 immer nur ein Symbol braucht.

Das alles weisz man „automatisch“ als Mensch, aber dem Computer muss man zu jeder Zeichenkette sagen, was die jetzt eigentlich fuer eine Bedeutung hat, damit die richtigen Operationen drauf ausgefuehrt werden. Und hat eine Zeichenkette erstmal eine Bedeutung, so aendert die sich niemals … … … jaja, ich weisz, dass es da Spezialfaelle gibt, die Ausnahmen zu dieser Aussage sind … aber mir geht’s hier darum, dass man einem Computer explizit und jedes Mal sagen muss, womit dieser eigentlich gerade arbeitet.
Das ganze geht natuerlich noch viel tiefer direkt rein in die Innereien des Computers. Denn eine Zahl ist im Speicher ganz anders dargestellt als ein Wort.

Worauf ich hinaus will ist das Folgende. Jedes Objekt im Program (also meine Zeichenketten) hat „Betriebskosten“ in Form von Speicherplatzbedarf wo eben die Bedeutung des besagten Objektes abgelegt ist. Diese „Betriebskosten“ beinhalten das was ich oben sagte, damit der Computer weisz, wie mit besagten Objekten umzugehen ist. Interessiert bin ich aber nur an der „Ladung“ eines Objektes; also der Zahl oder dem Wort an sich. Diese „Ladung“ kommt zu den „Betriebskosten“ hinzu.

Um die „Betriebskosten“ kommt man niemals drumherum und es gibt nun zwei Møglichkeiten, wie man das handhaben kann. Zentral oder dezentral.
Zentral bedeutet, dass man eine gewisse Menge Speicherplatz reserviert und ranschreibt welche Bedeutung alle Objekte die sich darin befinden haben. Dann muss man das nur einmal sagen und die „Betriebskosten“ fallen nur einmal an.
Dezentral bedeutet, dass man das an jedes einzelne Objekt ranschreibt. Dann fallen die „Betriebskosten“ fuer jedes Objekt an. Warum sollte man das machen? Naja, dafuer gibt es technische Gruende, und mindestens einen eher philosophischen Grund: um dem Menschen der das Programm schreibt die Arbeit zu erleichtern. Denn das ist genau das was Python macht. Speicher- und Objektmanagement sind Dinge, die man in anderen Programmiersprachen explizit machen muss. Ich finde das durchaus interessant, aber ich gebe zu, dass es vom eigentlichen Programmieren (sich logische Strukturen ueberlegen, die ein gewisses Problem løsen) abhaelt, wenn man das „Inventar“ immer „sortieren und sauber halten“ muss.

Und das ist das was ueber das Anfaengerprogrammiererniveau zumindest unter Python hinausgeht. „Anfaengerprogrammiererniveau“ deswegen, weil Python heutzutage nunmal die Sprache ist, in der mglw. die allermeisten Leute anfangen zu programmieren. Und die fangen damit an, eben weil da solche Sachen im Hintergrund passieren  und vom Menschen der den Code schreibt weg gehalten werden.
Es ist aber natuerlich auch Grund, warum Python nicht fuer die Programmierung wirklich groszer Programme (wie bspw. Betriebssysteme) benutzt wird. Hat halt alles seine Vor- und Nachteile.

Soweit dazu. Den Speicherbedarf der „Ladung“ habe ich oben berechnet. Aber wie grosz sind denn nun die „Betriebskosten“ pro Zeichenkette? Nun ja, das ist kompliziert und nicht nur von der Architektur des Rechners und Betriebssystems, sondern auch der benutzten Inkarnation der Programmiersprache abhaengig. Unter Python 3.7.3 auf meinem Rechner belaufen sich besagte „Betriebskosten“ von Zeichenketten auf 49 Byte pro Objekt. (Unter Python 2.7.16 sind es uebrigens nur 37 Byte).
Da wir 5,798,312 Wikipediaseiten und 165,913,569 Links haben kommen zu den obigen ca. 3 GB also nochmals 8,413,882,169 Byte hinzu. Eigentlich ein bisschen mehr, weil Sonderzeichen høhere „Betriebskosten“ haben, aber in der Summe sind das dann ungefaehr 11 GB.

Mhm … 11 GB das wird zwar knapp, aber so viel habe ich eigentlich. Warum kommt der Computer aber schon nicht mehr klar, wenn ich nur 10 Dateien eingelesen habe?
Ohne lange Rede: die Links sind in Sets (das ist sowas wie ’ne Liste ohne doppelte Objekte) angeordnet und davon habe ich natuerlich pro Titel eins. Insgesamt ist dann alles in einem einem sogenannten „Dictionary“ sortiert, damit ich zu jedem Titel leicht die zugehørigen Links finde (wie eben in einem Lexikon). Solche uebergeordneten Strukturen haben natuerlich auch Betriebskosten zusaetzlich (!) zu denen der einzelnen Elemente die in diesen Strukturen „aufbewahrt“ werden. Aber anders als bei den „primitiven“ Objekten wie oben beschrieben steigen die Betriebskosten in Abhaengigkeit von der Anzahl der Elemente die sich darin befinden. Klar, der gesamte Speicherbedarf eines Wortes ist abhaengig von der Anzahl der Buchstaben, aber das ist die „Nutzlast“. Die „Betriebskosten“ des Wortes sind davon unabhaengig. Und das ist bei den uebergeordneten Strukturen anders (weil die komplizierter sind und auch kompliziertere Operationen erlauben).

Zur besseren Veranschaulichung stelle man sich einen Gueterzug der Farbe transportiert vor. Alle Links die zu einem Titel gehøren entsprechen einer Farbe. Besagte Sets sind dann ein Tankwaggon, die jeweils nur eine Farbe enthalten. Wenn ich mehrere Tankwaggons habe, dann fallen die Betriebskosten (Wartung, oder Versicherung) pro Stueck an. Habe ich weniger Farbe, benutze ich einen kleineren Tankwagon, der geringere Kosten hat. Die Lokomotive (welche wiederum Betriebskosten hat) nun zieht alle Tankwaggons. Habe ich nur ein paar, benutze ich eine kleinere Lokomotive (mit geringeren Kosten), als wenn der Gueterzug so lang ist wie in Sibirien.

Und der Speicherbedarf dieser uebergeordneten Strukturen entwickelt sich selbst ohne die „Nutzlast“ dramatisch! Die „Waggons“ in denen sich die Links befinden benøtigen in ihrer kleinsten Form (also ohne Nutzlast, wenn ein Titel keine Links enthaelt) bereits 224 Bytes. Bei den ca. 6 Millionen Titeln macht das also mindestens (!) nochmal 1.3 GB. Und nun kommen wir in Regionen, wo mir der Speicher ausgeht.

Aber eigentlich braucht die Anordnung in Sets deutlich mehr, denn beim Maximum der Verteilung bzgl. der Anzahl der Links pro Titel, beansprucht ein Set bereits 736 Bytes Speicherbedarf an „Betriebskosten“. 736 Bytes braucht ein Set auch dann, wenn es 18 Elemente hat, aber ab 19 Elementen braucht es 2272 Bytes. Insgesamt sieht das dann so aus:

Puuuuh … das geht linear, nochmal Glueck gehabt … … … Oopsie, das sind ja doppeltlogarithmische Achsen! … … … Ach du meine Guete! Der Anstieg ist ja positiv! Damit wird ja der Exponent des maechtigen Gesetzes grøszer Null!

Lange Rede kurer Sinn: die vormals betrachtete, oben verlinkte, Verteilung der Anzahl der Links fuer alle Titel muss mit dem hier dargestellten Speicherbedarf _multipliziert_ werden. Das sieht dann so aus:

Mist! Die Ordinate ist linear und in Megabyte.

Erst jetzt ergibt das Integral unter dieser Kurve den tatsaechlichen Speicherbedarf dieser Ueberstruktur von Sets welche besagte Links enthalten: 10,962,695,936 Byte also ca. 11 GB die zu den obigen 11 GB noch dazu kommen. So viel Speicher habe ich nicht. Die „Lokomotive“ (das „Dictionary“), also die oberste Ordnungsstruktur, braucht dann bei ca. 6 Millionen Elementen nochmals 300 MB. Aber das faellt dann kaum mehr ins Gewicht.

Ich fasse zusammen. Der Speicherbedarf der eigentlichen „Buchstaben“ aller Titel und Links betraegt nur 3 GB. Aber die Verwaltung all dieser Buchstabenobjekte verursacht (in Python) „Betriebskosten“ von 8 GB. Die Strukturen in der die ganzen Objekte nun zusammengefasst sind verursacht dann nochmals „Betriebskosten“ in Høhe von weiteren 11 GB.
Kein Wunder, dass mein Computer da keine Lust drauf hat.

Wie ich dieses Problem løste stelle ich beim naechsten Mal vor. Denn die Løsung ist echt cool (weil so elegant) und erlaubte mir ueberhaupt erst das Gesamtproblem (die Erforschung des Linknetzwerkes) derart umzuformulieren, dass ein Computer das (schnell) løsen konnte.

Ach so … wenn ich hier 22 GB zusammenrechne, wie komme ich denn auf die 4.1 GB, die ich ganz oben erwaehne. Nun ja, wenn ich das alles auf der Festplatte speichere, dann wird die Struktur serialisiert. Dabei werden strukturierte Daten in einen seriellen Datenstrom „umgewandelt“ fuer die Speicherung. Darauf kann ich dann natuerlich nicht arbeiten.
Ich kønnte mir denken, dass viele von den „Betriebskosten“ gespart werden kønnten, indem man einen Teil des seriellen Datenstroms bspw. als „ab hier keine Zahlen sondern nur Wørter“ definiert (anstatt das fuer jedes Wort einzeln zu machen). Wenn das wieder zurueck „uebersetzt“ (de-serialisiert) wird, dann sieht der Algorithmus das und „baut“ daraus die richtigen Wortobjekte.
Aber das sollte alles als Spekulation gesehen werden, denn ich habe eigentlich gar keine Ahnung was da wirklich passiert.

Ich beschwerte mich die letzten paar Peanuts-Jahre, dass die Strips Routine geworden sind.

Zu meinem Erstaunen gab es aber doch noch ein paar Enwicklungen. Eher negativ war, dass Snoopy etwas „schrullig“ zu werden schien. Das fand ich eher schade. Mein Eindruck war in den ersten Jahrzehnten doch eher, dass dies der einzige Erwachsene in der ganzen Serie ist. Aber in einer Weise die sehr gut passt, denn er war ein Erwachsener, der sich ueberhaupt nicht kuemmerte, was „die Leute“ denken møgen, wenn er Freude am Leben hat und „Kinderkram“ macht.

Als jemand der „zu alt“ ist fuer Comics, Lego, Videospiele, (Wasser)Rutschen etc. pp. hat mich das natuerlich angesprochen.

Eine positive Enwicklung war aber bzgl. des Charakters der Peppermint Patty im letzten Jahrzehnt der Peanuts zu sehen. Sie ist natuerlich nicht komplett veraendert worden, aber ihr Charakter wurde doch sehr viel nuancierter. Und auf eine gewisse Art und Weise (nur eben anders) hat sie „Teile von Snoopy“ uebernommen. Nicht den Teil des „einziger Erwachsener in der Serie“. Ich meine vielmehr, dass es auch sie nicht kuemmert was „die Leute“ denken, wenn sie Freude am Leben, auch auszerhalb gesellschaftlicher Normen (als Maedchen das sog. „Jungskram“ macht). Das war zwar immer schon da, aber nun war es nicht mehr nur „schrullig“ sondern „ernsthaft“ … wie gesagt, in gewissem Sinne eine umgekehrte Entwicklung im Vergleich zu Snoopy.

Daraufhin aenderte sich meine Einstellung bzgl. dieses Charakters komplett … aber das hatte ich ja frueher schonmal angesprochen.

Und Marcy war eh schon immer fetzig … Sie ist uebrigens eins von zwei Maedchen die Hosen tragen. Das andere ist (natuerlich) Peppermint Patty.

Ausgehend von Kevin Bacon war der urspruengliche Plan das Linknetzwerk der Wikipedia zu untersuchen.
Dies ist im Grunde ein universelles (im Sinne von Universum) Problem — Die Beziehung von Informationen zueinander. Das habe ich dann gleich erstmal massiv auf Erdwissen eingeschraenkt welches sich in der (westlichen) Wikipedia befindet. Damit konnte ich das universelle Problem auf ein Sprachproblem reduzieren.
Das war aber immer noch zu viel, denn die Texte enthalten unheimlich viel Information, die im Sinne der Fragestellung „unbrauchbar“ ist. All das habe ich weggeschmissen und zurueck blieben die Titel von Wikipediaseiten und welche anderen Wikipediaseiten diese zitieren.

Das Wichtige an einem solchen Netzwerk sind nun aber nicht die Anzahl der „Knotenpunkte“. Ein Elefant hat deutlich mehr Neuronen als ein Mensch und dennoch sind es Fuszstapfen des Homo Sapiens auf dem Mond.
Nebenbemerkung: Gehirne sind urst krass kompliziert; bspw. haben grøszere Tiere im Allgemeinen auch grøszere Neuronen (die brauchen also mehr Platz). Und auch die Struktur des Gehirns (die Runzeln) oder in welchem Teil des Gehirns sich die Neuronen befinden ist wichtig. Und ich tu mal so, als ob es Vøgel nicht gibt.

Ganz generell ist also nicht die Menge der Knoten ausschlaggebend, sondern wie viele Verbindungen es zwischen den Knoten gibt. Selbst wenn ueber das Netzwerk jeder Punkt erreicht werden kann, so dauert es laenger, je mehr „Zwischenstops“ bei anderen Knoten man unterwegs einlegen muss. Oder anders gesagt: wer schaut sich schon die zweit oder gar dritte Seite mit den Sucherergebnissen an?
Diese Anzahl der Schritte bezeichnete ich am Anfang der Serie als „Linklevel“.

Zur Veranschaulichung nehme man dieses ausgedachte Beispiel:

Von Apfel (Linklevel 0, da das der Ursprung ist) komme ich direkt zu Baum, Frucht und Kuchen. Von Apfel aus gesehen liegen diese drei also auf Linklevel 1. Im Beispiel geht das Netzwerk bei Frucht nicht weiter. Von Baum aber geht es zu Borkenkaefer und Holz. Diese Beiden liegen von Apfel aus gesehen auf Linklevel 2 und von Baum aus gesehen auf Linklevel 1. Letzteres ist (erstmal) nicht von Interesse, denn hier interessiert uns nur Apfel und Baum wird separat untersucht.
Kuchen verweist nun zurueck auf Apfel. Das ist das, was ich spaeter „Selbstreferenz“ nennen werde, denn das ist ja prinzipiell auch von Interesse: wie entwickelt sich die Selbstreferenz je „weiter“ man weg ist vom Urpsrung? Natuerlich liegt fuer Kuchen der Apfel ebenso auf Linklevel 1 und via Apfel erreicht man dann von Kuchen aus die anderen Elemente (nur jeweils ein Linklevel høher). Auch dies wird in der Analyse separat betrachtet; ich erwaehne das nur, weil das aus dem Beispiel „heraus faellt“.

In einem zweiten Beispiel kommt Kirsche hinzu:

Das ist das Gleiche wie bei Apfel, nur von Kirsche aus gesehen ist Apfel auf dem selben Linklevel wie Holz (Linklevel 2) denn diese beiden „kommunizieren“ via den Knoten Kuchen. Umgekehrt gilt das natuerlich genauso.
Ich erwaehne dies, weil das Linknetzwerk absolut das Selbe (!) ist, trotzdem ein anderer Knoten als Ursprung genommen wurde.

Jetzt noch ein drittes Beispiel:

Von Apfel komme ich via Kuchen, Mehl und Weizen zu Pflanze. Von Pflanze komme ich dann zurueck zu Baum. Damit wuerde Baum (von Apfel aus gesehen) auf Linklevel 1 und Linklevel 5 liegen. Das wird aber ignoriert, weil ich sonst in Schleifen gerate, aus denen ich nicht heraus komme. Dadurch, dass Baum bereits auf Linklevel 1 „besprochen“ wurde ist das auch gerechtfertigt denke ich.

Ich habe das aus zwei Gruenden (nochmals) so ausfuehrlich beschrieben. Zum Einen, um nach all den vorhergehenden Analysen und Diagrammen das urspruengliche Problem wieder in Erinnerung zu rufen. Zum Anderen sieht man hieran, dass ich das Sprachproblem „mathematisieren“ konnte. Denn wie man an den Beispielen sieht, faellt das Kevin-Bacon-Problem in das Gebiet der Graphentheorie.
Von Letzterer habe ich keine Ahnung. Das hindert mich aber nicht daran, ganz praktisch und pragmatisch an die Sache heran zu gehen und eine Løsung zu finden, die gut genug fuer das ist, was ich eigentlich wissen will.

Damit genug fuer heute.

… ist Americium und dessen Isotop ²⁴¹Am wurde oft in Ionisationsrauchmeldern verwendet. Und so einer ist hier zu sehen:

Aufgrund offensichtlicher Gruende werden diese Art von Rauchmeldern heutzutage abgeløst durch rein optische Systeme.
Unwissend und arrogant wie ich mal war (vulgo: Alterweisheit liesz noch auf sich warten), machte ich mich frueher lustig ueber Leute, die vor „dem Atom“ Angst hatten. Aber die massenhafte Verbreitung von „solchen Atomen“ fuehrt doch unnøtige, (heutzutage) vermeidbare Risiken mit sich. Die geneigte Leserin oder der geneigte Leser møge sich nur mal den kurzen Abschnitt „Problematik“ im verlinkten Artikel anschauen.

Ich gebe aber zu, dass historisch gesehen ganz sicher viele Menschenleben durch diese Technologie gerettet wurden. Heutzutage geht das aber auch ohne ²⁴¹Am.
Wieauchimmer, obiger Rauchmelder ist kaputt und deswegen habe ich den mal aufgemacht und mich begrueszte (verstaendlicherweise) dieses bekannte Symbol:

Trotz Allem, schon cool wa! … Dennoch keine Sorge, denn ich werde nicht in den Fuszstapfen dieses Individuums folgen ;)

Wie imposant ein „Hot Jovian“ ist war mir von meiner Umrundung der Galaxis bereits bekannt. Aber der Anblick imponiert auch nach mehreren Malen:

Anders als beim ersten Mal entdeckte ich diesen Planeten nicht zufaellig. Ich flog hier bewusst her, denn auf dem Bild zu sehen ist Byeia Euq KK-W b29-11 A 1, der Helium-rich gas giant mit der kuerzesten Distanz zum Ankunftspunkt im System (nur 2 ls). Aufgrund dessen konnte ich zwei Dinge gleichzeitig tun: den Planeten mittels meiner Sonden kartographieren waehrend ich auftankte. Peak efficiency!

Anders als Megacorpse vom  letzten Mal ist 1 micromort keine absolute Grøsze sondern beschreibt die Wahrscheinlichkeit, dass eine Aktivitaet zum Tode fuehrt — mit einer Chance von 1 zu einer Million (daher das „micro“).

Das Risiko einfach nur am Leben zu sein fuehrt zu 24 micromort pro Tag. Das akkumuliert sich natuerlich durch die verschiedensten Aktivitaeten, welche man pro Tag ausfuehrt. Die Frage ist, wie weit man pro micromort kommt (wenn man sich bewegt) oder wieviel Spasz man pro micromort haben kann. Ich verweise an dieser Stelle hierauf, wo sich das mal wer anders genauer angeschaut hat (mit schicken Diagrammen) :) .

Ein Kindeheitstraum … oder vielmehr ein Traum meiner fruehen Jugend, denn Sat.1 kam spaeter in unseren Haushalt als bei anderen … wird wahr. Endlich kann ich alle Episoden der ThunderCats schauen:

Toll wa!

Im Sommer waren wir in Uppsala und weil Stockholm nicht weit weg ist, haben wir zwei Tagesausfleuge dorthin gemacht. Und wenn man als Nerd in Stockholm ist, dann ist ein Besuch im Science Fiction Bokhandeln Pflicht!
Besagten Laden kønnte ich jedes Mal wenn ich da bin leer kaufen. Dieses Mal ging ich (wie jedes Mal) rein, mit dem festen Vorhaben, dass ich nur gucken will, denn ich habe ja noch so viele andere Sachen zu lesen/schauen. Aber dann entdeckte ich obiges Komplettset einer Serie, die ich als junger Jugendlicher voll toll fand, von der ich aber nur ein paar Episoden gesehen habe.
Deswegen nahm ich mir vor ueber 25 Jahren vor, dass ich als Erwachsener dann mal alle Episoden auf Videokasette haben will. Nun ja, aus der Videokassettensammlung wurde (zum Glueck!) nichts. Aber als ich dann die oben gezeigte Box dort im Laden stehen sah, wurde (mal wieder) nix aus meinem Vorhaben. Ich habe (buchstaeblich) drei oder fuenf Sekunden gezøgert, weil ich in meinem Geiste die Frage ob ich das denn wirklich jetzt braeuchte logisch zu beantworten. Aber meine Freude darob dieses Fundes hatte laengst alle logischen Argumente ueberstimmt.

Deswegen wiederhole ich es nocheinmal: Thunder! Thunder! Thunder! Thundercats, Ho!
Die zweite Serie deren Eingangssequenz im verlinkten Video gezeigt ist — SilverHawks — ist ein weiterer Kindheistraum … ich bin gespannt, wann ich mir diese Kollektion zulegen werde … tihihihi.

Ansonsten wuensche ich ein ganz fantastisches 2022.

Nix, aber rein gar nix Organisches bleibt erhalten. Das ist als ein groszes Kreislaufsystem gedacht, in dem neues Leben (buchstaeblich) aus altem ehemaligem Leben entsteht.
Auch Fossilien aendern da nix dran, denn da werden ja die organischen Materialien durch inorganische ersetzt. So ein Stein in Knochenform haelt sich aber ’ne Weile laenger.

Worauf ich heute hinaus will ist, dass es leider keinen einzigen natuerlichen Mechanismus gibt, der Tøne bewahren kann.
Hochtechnologie hilft hier weiter, denn wenn man die Form von (relevanten) fossilisierten Dinosaurierkøpfen hat, dann kann man berechnen, was fuer prinzipielle Tøne damit erzeugt werden konnten.
Die verlinkte Seite lohnt sich uebrigens anzuschauen. Ist diese doch selber eine Art „digitales Fossil“ aus einer Zeit, als es noch eine „Site of the Week“ gab *kicher*.

Aber nur die Tøne (also Frequenz und Amplitude) sind ja nur der allererste Schritt fuer die Geraeusche. Und Computersimulationen kønnen wenig daruber sagen, wie besagte Tøne gestaltet wurden um dann die fuer eine Art typischen Dinosauriergeraeusche zu erzeugen.

Zum Glueck leben wir ja aber mit den Nachkommen der Dinosaurier auf dem selben Planeten. Somit kønnen wir zumindest von einigen die wahren Stimmen høren.

Hier ist ein Video von einem Schuhschnabel. Was fuer ein prachtvoller Vogel … pardon, ich meine natuerlich Dinosaurier! Diese schønen Wesen werden ueber einen Meter grosz. Und wenn man sich die Krallen oder den Schnabel mal anschaut, dann faellt es gar nicht schwer, die Aehnlichkeit zu Theropoda (vulgo (und extrem veraltet und soweit ich weisz nicht mehr im wissenschaftlichen Diskurs verwendet): Raubsaurier) zu erkennen.

Und bei 43 Sekunden spricht dieses praechtige Wesen zu uns … krassomat!

Aber das ist noch nicht alles. Im verlinkten Wikipediaartikel erfaehrt man, dass diese schønen Tiere noch viel mehr mit ihren Stimmen machen kønnen:

[…] adult birds have also been noted to utter a cow-like moo as well as high-pitched whines. […] When young are begging for food, they call out with a sound uncannily like human hiccups. In one case, a flying adult bird was heard uttering hoarse croaks, apparently as a sign of aggression at a nearby marabou stork […].

Voll toll! Auch wenn man dadurch bewusst wird, dass die (ebenso tollen) Computersimulationen eben doch nicht alles aufdecken kønnen. Aber das ist eine ganz andere Diskussion und ich wollte eigentlich nur mal das Video zeigen.