Søren in Norwegen

Bereits frueh stiesz ich auf das damals so benannte „São-Paulo-FC-Artefakt“ und es begegnete mir innerhalb des Kevin Bacon Projekts immer und immer wieder. Artefakt deswegen, weil ich zunaechst dachte, dass es durch die Behandlung der Daten vor der eigentlichen Linknetzwerkanalyse zustande kam. Weitere Untersuchungen zeigten aber, dass das gar kein Artefakt ist, sondern ein Phaenomen innerhalb der Wikipedia welches sich allgemeiner beschreiben laeszt.

Zur Auffrischung und ganz kurz, handelt es sich dabei um thematisch zusammenhaengende Seiten die (mehr oder minder, aber oft buchstaeblich) chronologisch sortiert sind und bei der eine Kettenseite jeweils nur die direkt nachfolgende (oder vorhergehende, aber das ist nicht zwingend) zitiert. Das bedeutet, dass bei der Linknetzwerkanalyse alle anderen (nicht zur Kette gehørenden) Seiten ein Kettenglied nach dem anderen „durchschreiten“ muessen. Dies wiederum erklaert andere Beobachtungen. Insbesondere den langen „Schwanz“ in den gemessenen Grøszen, obwohl die allerallerallerallermeisten Seiten bereits nach weniger als 10 Linkleveln den allerallerallerallergrøszten Teil ihres Linknetzwerks gesehen haben.

Ich setzte mich dann daran solche Kettenseiten systematisch zu finden und das hab ich im Zuge der Reproduktion natuerlich nochmal neu gemacht.

Das Wichtigste zuerst: in den neueren Daten (von Ende 2023) gibt es das „São-Paulo-FC-Artefakt“ noch … da freue ich mich, denn es ist mir irgendwie ans Herz gewachsen. Es ist aber nicht mehr die laengste Kette sondern nur noch die viertlaengste und bereits auf LL₃₅ hørt man das letzte Mal von ihr. Das ist natuerlich keine Kuerzung der Kette an sich ist, sondern kommt sicherlich durch eine bessere Verlinkung der Seiten zustande.

Der neue Kettenkønig sind die Tage des Meshir (ein Beispiel) … Huh? 30 Tage sind doch gar nicht lang genug. Wie kann das bis LL₇₈ durchhalten? Die Erklaerung liegt darin, dass dies nur eine Teilkette ist, die rueckwaerts gehend mit den Tagen des Tobi (ein Beispiel) und dann des Koiak (ein Beispiel), und irgendwie vorwarts gehend aber mlgw. parallel (?) mit den Tagen des Paremhat (ein Beispiel) eine zusammenhaengende Kette bildet. Wobei die Verlinkungen sicherlich komplizierter sind als beim „São-Paulo-FC-Artefakt“ (welches der Tradition wegen weiterhin von mir als „Artefakt“ bezeichnet wird). Letzteres endet naemlich wie erwartet in 1930, …

[…] the first competitive season of São Paulo Futebol Clube […]

… waehrend der neue Kettenkønig hingegen bereits bei Meshir 18 stoppt. Es gibt da sicherlich auch ’ne Art „Archipelstruktur“ zwischen den einzelnen Seiten und wie angedeutet besteht eine Kette mglw. aus mehreren teilweise parallel laufenden, mehr oder weniger langen „Straengen“. Insgesamt aendert das aber nichts am Phaenomen an sich, solange die sich mehr oder weniger immer noch nur der Reihe nach zitieren und (vom Einstieg in die Kette abgesehen) nicht von Seiten auszerhalb der Kette zitiert werden … Kette ist Kette.

Die Verbindung von Teilketten zu einer langen Kette (was ja letztlich dann doch nur eine Kette ist) bringt mich zu einem wichtigten Punkt: Aenderungen im Algorithmus um Kettenseiten zu finden. Denn natuerlich schrieb ich den dazugehørenden Code nochmal neu und implementierte dabei einen vernuenftigeren Algorithmus … und das fuehrt natuerlich zu Unterschieden (wenn auch nicht all zu groszen) in den Resultaten.

Der damalige Algorithmus war ein „Kind seiner Entstehung“. Man sieht ueberall wie ich mit einer Idee anfing und im Laufe der Zeit immer mehr ueber dieses Phaenomen lernte. Dieses neue Wissen flosz dann stueckchenweise in den Code zurueck, ohne vorherigen Ablaeufe wesentlich zu aendern..
An der Identifikation potentieller Kettenseitenkandidaten hat sich nix signifikantes geaendert. Weiterhin werden nur solche Seiten betrachtet, die im Linkfrequenzsignal zum Einen bei einem (sehr) niedrigen Linklevel ein (sehr) kleines Signal aufweisen und zum Zweiten das Maximum jenseits eines gewissen (mehr oder weniger) hohen Linklevels haben. Ich erhøhte bzgl. Ersterem das Linklevel nur um eins (von LL₄ zu LL₅) und erniedrigte den erforderlichen Wert (von 23017 (welches sowieso 23517 haette sein sollen) zu 420 … aber das sind sowieso relativ willkuerliche Werte, es kommt nur drauf an, dass die grosz genug sind).

Damals sortierte ich dann von allen Kandidaten diejenigen aus, die den gleichen „Titelstamm“ (vulgo: „Familienname“) hatten (also bspw. „São Paulo FC season“ und das entsprechende Jahr am Anfang der jeweiligen Titel). Seiten die derart zusammengefasst werden konnten nannte ich „regulaere Familien“. Hier sieht man bereits, dass diese Herangehensweise NICHT den obigen (neuen) „Kønigskette“ zutage geførdert haette, denn dort kommen mehrere „Familien“ zu einer Kette zusammen. Alle derartig identifizierten Seiten wurden dann in den nachfolgenden Schritten nicht mehr mit einbezogen.

Bei den Kandidaten die nicht „regulaeren Familen“ zugeordnet werden konnten schaute ich dann, ob die von anderen, ebenso nicht „regulaeren Familen“ zugeordneten Kandidaten, zitiert wurden. War dies der Fall, wurden solche Seiten als potentiell zu „Patchworkfamilien“ zugehørig angesehen. War dies nicht der Fall, wurden sie als potentielle „Anhaenger zu regulaeren Familien“ eingeordnet.
Letztere wurden zu „echten“ „Anhaengern zu regulaeren Familien“ wenn diese auch von Seiten in „regulaeren Familien“ zitiert wurden. Der Rest wurde komplett aussortiert.

Als letztes schaute ich bei potentiell zu „Patchworkfamilien“ zugehørigen Kandidaten rueckwaerts (und NUR rueackwaerts) rekursiv, von wem die Seiten zitiert werden. Dabei wurden nur andere potentiell zu „Patchworkfamilien“ zugehørige Kandidaten beruecksichtigt. Auf diese Weise habe ich „Patchworkfamilien“ rekonstruiert.

Nun zum wichtigsten Unterschied im neuen Algorithmus: Ketten werden ZUERST via des erwaehnten rekursiven Algorithmus rekonstruiert. Dabei gehe ich jetzt aber rueckwaerts UND vorwaerts die Kette entlang. Ich folge also wieder von wem eine Seite zitiert wurde (rueckwaerts) aber neuerdings auch wen die besagte Seite selbst zitiert (vorwaerts). Das faengt zum Einen alle „Kettenglieder“ auf und erlaubt somit die Rekonstruktion der neuen Kønigskette. Zum Zweiten werden sofort alle „Anhaenger“ einer Familie als eben dieser Familie zugehørig erkannt (und zugeordnet). Und zum Dritten muessen „Patchworkfamilien“ nicht in einem extra Schritt zusammengebaut werden.

Danach sortiere ich „Ketten“ mit zwei oder gar nur einer Seite aus und schaue bei allen anderen Ketten ob diese „Kettenglieder“ mit einem gemeinsamen „Familiennamen“ enthalten. Ist dem so, so nehme ich (im Wesentlichen wie vorher, nur auf eine andere Art) eine Unterteilung in „Kernkettenmitglieder“ (vulgo: die „Familie“) und Anhaenger vor.

Die Resultate sind im Wesentlichen die gleichen, es kommt im Speziellen aber natuerlich zu mehr oder weniger groszen Abweichungen … die Diagramme dazu dann aber beim naechsten Mal.

Ach so, das noch: die Meshir-Kette gab es in den 2020 Daten noch nicht; ich habe die damals also mitnichten „uebersehen“.

Und das auch noch: Die Begriffe „Kette“ und „Familie“ sind im Wesentlichen synonym und werden in diesem und den nachfolgenden Beitraegen auch in dem Sinne benutzt. Das „im Wesentlichen“ ist aber wichtig. Bspw. ist es oft sinnvoller den Begriff „Familie“ in vielen Zusammenhaengen zu verwenden, weil das die zugrundeliegenden Konzepte besser veranschaulicht. Das Ganze ginge aber auch mit dem Begriff „Kette“, waere nur etwas umstaendlicher.
Es gibt aber auch ein paar Situationen wo es doch einen Unterschied macht. Wo „Familie“ doch nicht das Gleiche vermittelt wie „Kette“ und auch nicht ganz richtig waere. Ich werde das dann nicht extra erwaehnen, das sollte sich aber aus dem Kontext erschlieszen.

Die damals „kollektive Wanderung“ genannten Beitraege waren mein eher weniger erfolgreicher Versuch die Idee der Grøszenordnungskomprimierung der massiven Daten „unter’s Volk“ zu bringen. In den letzten drei Beitraegen habe ich diese Methode stark verbessert, ausfuehrlich besprochen und einem nuetzlichen Zweck zugefuehrt.
Derartige Heatmaps sind aber so verschieden, dass man zwar im Prinzip das Gleiche hat wie bei den verlinkten Beitraegen, aber es ist irgendwie auch doch ganz anders.

Wieauchimmer, weil ich das so gut vorbereitet habe, muss ich heute gar nicht viel Aufhebens darum machen, was hier zu sehen ist:

Und tatsaechlich, alles was man sieht wurde bereits an verschiedenen Stellen besprochen. Zu erwaehnen sind nur zwei Dinge.

Erstens: dass sich die Verteilungen der Selbstreferenzen nach einem maechtigen Gesetz verhalten, schlaegt sich natuerlich in den Heatmaps nieder. Dies ist uebrigens einer der speziellen Faelle, in denen man die „Stufen“ durch die Komprimierung korrigieren kønnte, weil sich die Daten „gutartig“ verhalten.

Zweitens: die andere „Art“ von „Stufen“ (besprochen beim letzten Mal) ist beim Uebergang von den Hundertern zu den Zehner in den 2023-Daten keine richtige „Stufe“ mehr sondern scheint ein mehr oder minder linearer „Abstieg“ des Signals zu sein. Andererseits ist dieser Bereich sehr breit und was ich hier sehe scheint eher einer „Spaltung“ (auch beim letzten Mal besprochen) der 2023-Verteilungen in diesem Bereich zuzuschreiben zu sein.

Man sollte auch nie vergessen wo man herkommt und wie die bunten Bilder da oben dem linearen menschlichen Verstand eigentlich gegenueberstehen:

Der Vergleich logarithmischer und linearer Daten ist durchaus nuetzlich, letztlich steckt hier aber nix drin, was ich nicht schon gesagt haette … dieser Teil des Kevin Bacon Projekts heiszt ja nicht umsonst „Reproduzierbarkeit“.

Juti … damit ist diese Sache auch fertig. Eigentlich wollte ich die gar nicht reproduzieren, weil das damals so unzufriedenstellend war. Aber dann bin ich bei einem Spaziergang endlich drauf gekommen, wie man richtig an die Grøszenordnungshistogramme heranzugehen hat und dass ich die nicht fuer den urpsruenglichen Zweck (in normalen Diagrammen) verwenden sollte. Das hat mich natuerlich voll motiviert den dazugehørigen Code (nochmal) zu schreiben und die verbesserte Reproduktion war dann ein Klacks.

Alles in allem bleibt nur zu sagen: die Reproduktion der „kollektiven Wanderung“ geschah vøllig anders, ist aber gelungen.

Endlich bin ich bereit, all das in den letzten beiden Beitraegen Geschriebene, in ein einziges (bewegtes) Bild zu kondensieren. Hier ist es, …

… das Diagramm, fuer das ich die meiste Zeit brauchte. Nicht nur innerhalb dieses Projekts, sondern auch bzgl. der tausende von Diagramme die ich in meinem ganzen Leben bisher erstellt habe. Mehr als 12 Stunden Arbeit stecken hier drin. Und das zaehlt nicht mal mit, dass ich die linke Seite (fast) komplett von vorher recyceln konnte. Ich gebe zu, dass die Verantwortung bzgl. dieses immensen Zeitaufwands komplett bei mir und meiner pedantisch Art liegt … aber ich møchte halt jede Null und jeden Tick genau ausgerichtet (und abgerundet) haben. Und weil’s nur ein Diagramm ist, mit vielen verschiedenen Arbeitsschritten, war’s auch nicht sinnvoll das zu automatisieren (wie beim letzten Mal).

Wieauchimmer, in dem Bild sieht man das vormals beschriebene Prinzip anhand der Entwicklung der totalen Links aller Seiten (die linken Diagramme) der 2020-Daten, uebertragen auf eine Grøszenordnungsheatmap (rechte Seite).

In der Heatmap ist die „zeitartige“ Entwicklung, also die unterschiedlichen Linklevel, welche in den linken Diagrammen nur eins nach dem anderen zu sehen sind, auf der Abzsisse abgetragen. Die Abzsisse der linken Diagramme wird in Grøszenordnungseimer „transformiert“ und dann auf die Ordinate in der Heatmap uebertragen. Und die Ordinate der linken Histogramme wird so wie sie ist in die dritte Dimension, die Falschfarbenskala transformiert.

Natuerlich ist die Heatmap eigentlich sofort da, aber das ist ja nicht der Fall mit der animierten Sequenz von Histogrammen auf der linken Seite. Deswegen ist der rechte Teil der (jeweiligen) Heatmap schwarz. Ebenso schrieb ich:

[…] seien wir ehrlich, wenn die letzten Frames des bewegten Bildes gezeigt werden, hat man (nicht nur) die Details der ersten Frames schon vergessen […].

Diesen „Effekt“ versuche ich durch den „verblassten“ linken Teil der (jeweiligen) Heatmap darzustellen — alle Informationen sind eigentlich da, aber irgendwie nicht so klar.

Alles in allem: eine voll geile grafische Darstellung des Prinzips der Grøszenordnungshistogramme in Heatmaps. Fetzt voll wa!

… … …

… … …

… … …

Genug gezeappelt, schlieszlich hab ich all das ja nur geschrieben um genau davon weg zu kommen und nur noch das hier zeigen zu kønnen:

Die beim letzten Mal beschriebenen „Stufen“ sind natuerlich nur dann zu sehen, wenn sich das Histogramm auch wirklich ueber mehrere Grøszenordnungen ausdehnt. Deswegen sieht man dieses Phaenomen wirklich gut nur bei den Streifen der ersten drei, vielleicht vier Linklevel. Zum Beispiel bei LL₁, von unten nach oben gehend, ist der Abschnitt zwischen 100 und 1000 recht einfarbig. Bei 2000 dann nimmt die „Intensitaet“ des Streifens abrupt zu um bis 10-tausend wieder abzunehmen. Bei 20-tausend (und weniger stark nochmal bei 200-tausend), passiert das Gleiche nochmal. Das sind besagte „Stufen“.
Die besprochene Generalisierung dieses Phaenomens (Zunahme des „Grøszenordnungssignals“ nicht nur an einer „Stufe“ sondern ueber mehrere Werteeimer), sieht man bei genauem Hinschauen an den oberen Enden der Streifen fuer LL₄ und LL₅.

Interesseant sind zwei neue Beobachtungen in der Heatmap, die so nicht so leicht in den animierten (normalen) Histogrammen zu sehen sind und die ich auch nicht erwartet hatte, aber haette erwarten kønnen.

Zum einen gibt es in der Heatmap selber „Stufen“ einer anderen Art im Signal. Ich meine die abrupte Abschwaechung des Signals von LL₂₂ zu LL₂₅ und dann nochmal von LL₄₄ zu LL₄₉.
Das ist zum Glueck leicht zu erklaeren, insb. mit Blick zurueck auf die animierten Histogramme. Ab LL₁₂ ist dier ueberwiegende Teil des Signals in den Bereich der „Tausender Werteeimer“ zu finden. Das Signal hat also Werte von 10-tausend bis 2000. Dieser Bereich der „Tausender Werteeimer“ wird innerhalb von 10 Linkleveln (eben bis LL₂₂) „ueberwunden“. Oder anders: die Dynamik des Prozess durchschreitet mit nur zehn Schritten die Werte von 10-tausend bis 2000. Diese Dynamik wird langsamer je naeher es der 2000 kommt … aber letztlich „knallt“ es mit „hoher Geschwindigkeit“ in den Bereich der „HUNDERTER Werteeimer“. Aber von 1000 zu 900 sind nur einhundert Werte zu „durchschreiten“. Wenn der Prozess da also mit einer „Geschwindigkeit“ von (ich sag jetzt mal) „500 Werte pro Linklevel“ „draufknallt“, dann durchlaeuft der Prozess die Werteeimer von 1000 bis ca. 500 natuerlich in Null komma Nix … oder genau gesagt: innerhalb von nur zwei Linkleveln. Das fuehrt zu der zu sehenden „Stufe“ im Signal. Dass es ueberhaupt zwei Linklevel braucht liegt daran, weil die Dynamik rapide langamer wird.
Das Gleiche passiert beim Uebergang zu den „Zehner Werteeimern“, weswegen dort eine weitere „Stufe“ in der Heatmap zu sehen ist.

Die zweite neue Beobachtung ist innerhalb dieser zweiten „Stufe“ zu sehen. Dort scheint das Signal sich in zwei Bereiche aufzuspalten. Wenn man genau hinschaut, dann sieht man das (sehr schlecht) in den normalen, animierten Diagrammen. Als ich das reproduziert hatte, zeigte ich ein Extrembeispiel dieses Phaenomens in den 2023-Daten in einem gesonderten Diagramm. Aber in den Histogrammen der 2020-Daten ist mir das bisher nicht aufgefallen, eben weil die Datenpunkte dort so dicht beeinander liegen, dass ich das buchstaeblich nicht gesehen habe.
Die neue Methode der Darstellung von Information enthuellt noch mehr  Sachen die bisher „versteckt“ waren als angenommen. Fetzt wa!

So, das soll reichen fuer heute. Beim naechsten Mal dann endlich zurueck zur Reproduktion.

Ach so … eins noch: die Ordinate der Heatmap hat _zwei_ lange Striche am unteren Ende. Einen fuer „Werteeimer 0“ und einen fuer „Werteeimer 1“. Normalerweise achte ich pedantisch (siehe oben) darauf, dass sowas nicht passiert.
Hier ist das aber volle Absicht, denn die Null gibt es in logarithmischen Diagrammen ja gar nicht … bzw. liegt die bei minus Unendlich. In normalen Diagrammen hab ich die dazugehørenden Datenpunkte frueher erst einfach reingepackt und gesagt, dass die einen Wert von Null haben. Seit einger Zeit unterbreche ich die Achse an der entsprechenden Stelle. Bei Grøszenordnungshistogrammen ist das aber kein Problem mehr, denn der Wert Null bekommt einfach seinen eigenen Werteeimer.
Nun ist es aber so, dass die Ordinate immer noch ’ne „logarithmische (numerische) Bedeutung“ hat. Und da wird dem Wert Eins ein langer Strich zugeordnet. Das wollte ich gerne beibehalten. Dem „Werteeimer 0“ einen kurzen Strich zu geben fuehlte sich aber auch nicht richtig an, denn das kommt einer „Verlaengerung“ der Achse mit logarithmischer Bedeutung zum Wert Null (was ja nicht geht) zu nahe. Deswegen lasse ich den mit Absicht etwas herausstechen (Wortspielkasse); auch um auf die Andersartigkeit dieser Art der Darstellung von Information hinzuweisen.

Nachdem ich beim letzten Mal das (zugegeben SEHR spezifische) Problem im Detail erklaerte, folgt heute nun die (ebenso detaillierte) Erklaerung der Løsung. Es wird also wieder technisch und kleinteilig.

Ich erwaehnte bereits, dass die …

[…] Verteilung ueber mehrere Grøszenordnungen […] mittels logarithmisch, unterschiedlich grosze Werteeimer hantiert [wird].

Und das Prinzip hatte ich damals auch schon mal erklaert und recht erfolglos angewendet. Ich habe die damalige Methode etwas modifiziert, aber der Grundgedanke bleibt der Selbe und der geht so.
Zunaechst denke man sich einen Strich auf einer einer logarithmischen Achse; bspw. bei der 20 oder der 700. Dort wird ein Werteeiner hingestellt, und alle Werte die vor diesem Strich liegen (aber HINTER dem vorherigen Strich) werden in diesen Werteeimer sortiert. Im ersten Beispiel also alle Werte von 11 bis 20, im zweiten Beispiel alle Werte von 601 bis 700 … der Wert der genau auf dem Strich liegt kommt also auch mit rein.
Weil die Werteeimer auf den Strichen einer logarithmischen Skale „gestellt“ werden, nenn ich das Grøszenordnungshistogramm.

Das beim letzten Mal besprochene Problem mit Verteilungen ueber mehrere Grøszenordnungen brachte mich schon sehr frueh auf die Idee der Grøszenordnungshistogramme … das fuehlte sich irgendwie richtig an, dass das besagte Problem damit handhabbar wird. Aber meine Werteeimer gingen ueber eine gesamte Grøszenordnung (also bspw. von 1,000,001 bis 10,000,000) und das war „zu grob“ und deswegen ging das was ich mir ausmalte nie auf.
Ich denke, das lag auch daran, dass ein Wert von bspw. 5,000,000 (die Mitte des Beispiels) im Wesentlichen genauso nahe an der 10 liegt (also sechs Werteeimer vorher), wie an der oberen Grenze des Werteeimers in dem die tatsaechliche Einsortierung dann stattfand. Und viel naeher an allen Werteeimern dazwischen. Die viel kleineren Intervalle løsen dieses Problem (was mir uebrigens schon damals „Bauchschmerzen“ bereitete) und machen die Methode damit praktikabel.
Hinzu kam auch, dass ich das nur in normalen Diagrammen verwenden wollte … was mir nicht besonders nuetzlich schien und scheint (siehe das verlinkte Beispiel); ich hatte einen passenden Anwendungsfall also noch nicht erkannt.

Wieauchimmer, bevor ich zu den Heatmaps komme møchte ich zunaechst auf zwei Besonderheiten von Grøszenordnunghistogrammen hinweisen, die auf die oben beschriebene Art hergestellt werden. Beide sind in diesen beiden Grafen zu sehen:

In beiden Diagrammen benutze ich Daten aus 2020. Im linken Bild sieht man die Histogramme der totalen Links auf Linklevel 0 und im rechten Bild das Gleiche, aber auf Linklevel 3. Die grauen Balken bzw. Punkte sind das normale Histogramm (kein Binning) und die roten Balken bzw. Punkte sind das Grøszenordnungshistogramm.

In Letzteren sieht man in beiden Faellen an den „Grenzen“ wo die Werteeimer pløtzlich grøszer werden „Stufen“. Das ist am leichtesten an einem Beispiel zu erklaeren.
Im Werteeimer and der Stelle 100 befinden sich maximal 10 Werte (91 bis 100). Im Werteeimer an der Stelle 200 hingegen kønnen sich bis zu 100 Werte befinden (101 bis 200), also 10 Mal mehr. Das ist hier auch tatsaechlich der Fall. Wenn nun die Anzahl der Seiten die zum Zaehler im zweiten (grøszeren) Intervall beitragen nicht schnell genug abnimmt, dann wird der entsprechende Balken im Grøszenordnungshistogramm grøszer als der davor liegende Balken, obwohl im normalen Histogramm alle Balken (im Wesentlichen) fortfahrend kleiner werden.

Wenn die Daten sich „gut“ verhalten (bspw. normalverteilt sind oder schnell genug abfallen … das kann man mathematisch sicher genau definieren), dann kann man das korrigieren. Im linken Diagramm kønnte man bspw. den Grøszenordnungshistogrammzaehler durch die Anzahl der originalen bins die in einen gegebenen Grøszenordnungseimer passen dividieren. Macht man das, so kommt die Høhe der roten Balken, denen der grauen Balken an den entsprechenden Stellen sehr nahe.
Im Allgemeinen funktioniert das aber nicht und im rechten Bild fuehrt die gleiche Methode zu grobem Unfug. Deswegen habe ich mich entschlossen die „Stufen“ einfach drin zu behalten und „anzuerkennen“. Das muss man also bei der Interpretation von Grøszenordnungshistogrammen im Hinterkopf haben.

Ein Nachteil muss das Ganze aber mitnichten sein. Diese Aussage manifestiert sich im rechten Diagramm, denn es zeigt eine Verallgemeinerung dieses Phaenomens. Dort gibt es im Grøszenordnungshistogramm nicht nur „Stufen“ an den „Grenzen“ zwischen Werteeimern unterschiedlicher Grøsze. Selbst innerhalb eines Abschnitts wo die Werteeimer alle die selbe Grøsze haben, hat die „Signalstaerke“ einen positiven Anstieg. Und das sogar obwohl im originalen Histogramm die Høhe der „Balken“ mitnichten monoton ansteigt. Ich gebe zu, dass man vermutlich etwas genau hinschauen muss um das zu sehen, insb. bzgl. der letzten Aussage. Am leichtesten ist es im Abschnitt von 10⁶ bis 10⁷ zu erkennen.
Aber genau darin liegt auch der Grund, warum das beschriebene Phaenomen kein Nachteil sein muss. Wie gesagt, kommt die „Erhøhung“ des „Signals“ im Grøszenordnungshistogramm dadurch zustande, dass da „mehr Zeuch“ in die Werteeimer „geschmissen“ wird. Im normalen Histogramm sieht man aber nicht, dass da mehr „Zeuch“ in dem Abschnitt liegt — die Punkte sind da so dicht, dass dort zum Teil buchstaeblich Millionen von Datenpunkten uebereinander liegen und damit ununterscheidbar werden. Das ist also ein „man-sieht-den-Wald-vor-lauter-Baeumen-nicht“ Problem … bzw. habe ich das an anderen Stellen als „logarithmische Komprimierung“ bezeichnet.
Beim Vergleich der unterschiedlichen Histogramme muss man aber fuer den Anstieg (bzw. die „Stufen“) im Grøszenordnungshistogramm eine Erklaerung finden … und damit wird man automatisch darauf aufmerksam, dass es da noch urst viel „Zeuch“ geben muss, was man so im normalen Histogramm nicht sieht. Natuerlich muss man auch das bei der Interpretation im Hinterkopf behalten.

Soweit dazu, der Rest geht nun ganz schnell.

Die obigen Bilder sind immer noch normale, doppellogarithmische Diagramme. Den Werteeimern wird (mindestens unbewusst) ein numerischer Wert zugeordnet. Deswegen entgehen wir auch im Grøszenordnungshistogramm nicht dem Fakt, dass die Werteeimer unterschiedliche Abstande voneinander haben. Letzteres wuerde (immer noch) zu unterschiedlich groszen Pixeln in einer Heatmap fuehren.
Nun schrieb ich aber nicht umsonst immer „Werteeimer“, denn ich will die „numerische Interpretation“ „wegabstrahieren“.
In aller Kuerze: fuer die Heatmap tue ich so, als ob die Werteeimer alle gleich grosz sind und schiebe die dann dicht an dicht. Dadurch werden alle Pixel gleich grosz.
Auch hier muss man bei der Interpretation einer solchen Heatmap im Hinterkopf behalten, dass die Werteeimer selbstverstaendlich (auch) eine „numerische Interpretation“ haben, somit auf der entsprechenden Skala natuerlich NICHT den gleichen Abstand haben und auch nicht alle gleich grosz sind. Aber wenn man erstmal so weit gekommen ist und alles bis hierher verstanden hat, dann sollte das kein Problem sein.

Und damit bin ich fertig fuer heute. Beim naechsten Mal dann endlich die Anwendung dieser Methode

Heute wird’s etwach technisch und sehr „kleinteilig“ … das ist aber dafuer da, um die Fetzigkeit des (im uebernachsten Beitrag zu sehenden) Fetzigen zu verstehen :) .

In diesem Projekt hab ich (sehr) viele Verteilungen von (nicht nur „Mess-„) Grøszen gezeigt. Das nennt man auch Histogramm … und hier geht’s schon los mit dem Problem, denn die Konstruktion eines Histogramms beginnt eigtl. mit dem „binning“ der Daten (das ist auch der dtsch. Begriff o.O ) … und das hab ich allermeistens nicht gemacht (darauf gehe ich weiter unten ein).
Natuerlich zeigen alle hier gemeinten Grafen Verteilungen; konkret: die Anzahl der Wikipediaseiten, die einen bestimmten Wert fuer eine grøsze von Interesse haben. Deswegen sind’s eben doch alles Histogramme.

Wieauchimmer, ich erwaehnte bereits, dass ich die Daten in den meisten Faellen nicht gebinnt habe. Und der Grund ist, dass die Verteilungen sich ueber mehrere Grøszenordnungen erstrecken.
Histogramme kommen meist mit gleich groszen „Werteeimern“ … auf dtsch.: Klassen, aber das hørt sich nicht so spaszig an wie „Eimer“ und Datenanalyse ist spaszig) … in welche die entsprechenden Beobachtungen einsortiert werden. Es ist møglich unterschiedlich grosze Werteeimer zu haben, aber deren Nutzen ist eher begrenzt (weswegen die nicht sehr haeufig zu sehen sind) und wenn sich die Darten ueber mehrere Grøszenordnungen erstrecken, dann hilft auch das nicht mehr.

Wenn die Daten nicht gebinnt sind, dann kann man bei normalen Diagrammen (oft doppelt) logarithmische Skalen benutzen um das Problem der „Undarstellbarkeit“ einer Verteilung ueber mehrere Grøszenordnungen verschwinden zu lassen.

Da scheint das Problem geløst, aber an dieser Stelle tut sich innerhalb des Projekts an vielen Stellen ein damit gekoppeltes, zweites Problem auf. Nicht nur erstrecken sich viele Verteilungen ueber mehrere Grøszenordnung, sondern es gibt auch eine „zeitartige“ Entwicklung.

„Zeitartige“ Entwicklungen kann man dem Publikum im Wesentlichen in drei Formen praesentieren: als repraesentative Beispiele, als bewegtes Bild, oder als pseudo-3D Falschfarbenbild … vulgo: Heatmap (wieder: auch auf dtsch.) (Achtung: in dem verlinkten Beitrag sind KEINE „zeitartigen“ Entwicklungen zu sehen, es soll nur als Beispiel fuer Heatmaps herhalten).

Ersteres hat den Nachteil, dass man die „Dynamik“ eines Entwicklungsprozess anhand statischer Bilder nicht so richtig schøn sieht. Das ist aber eigentlich nicht so schlimm, denn es soll ja nicht unbedingt schøn aussehen, sondern stimmen. Und da liegt der schwerwiegendere Nachteil, denn man kann in den nicht gezeigten Daten die „Ungereimtheiten“ „verstecken“ und sich dann (mehr oder weniger zu Recht, oft (!) zurecht) mit dem Wort „repraesentativ“ rausreden.
Das hab ich bei allen meinen wissenschaftlichen Projekten so gemacht; natuerlich nur in (gerechtfertigten!) Ausnahmefaellen … und ja, auch bei denen, fuer die ich mit zwei Doktortiteln belohnt wurde … und auch in diesem hier. Alle anderen (mit realen Messdaten arbeitenden) Wissenschaftler machen das auch und es funktioniert. Wie gesagt: mehr oder weniger zu Recht, oft (!) zurecht. Als Beispiel fuer diese (durchaus legitime) Herangehensweise auch in der ganz groszen Wissenschaft, kann wer Interesse daran hat mal versuchen, mehr ueber die Daten in der Aequatorregion der (beruehmten) Planck Karte des kosmischen Mikrowellenhintergrunds herauszufinden. Wieauchimmer, das potentielle Problem repraesentativer Beispiele bleibt bestehen.

Zweiteres sieht imponierend aus … funktioniert aber nur digital … und seien wir ehrlich, wenn die letzten Frames des bewegten Bildes gezeigt werden, hat man (nicht nur) die Details der ersten Frames schon vergessen … *seufz* … schade um die viele Arbeit :( .

Dritteres ist am schwersten zu verstehen … aber wenn man’s verstanden hat, dann versteht man auch, warum es eine der coolsten Arten ist, dreidimensionale Information darzustellen, denn man hat alles Wesentliche sofort im Blick.
Fuer „zeitartige“ Evolutionen, bspw. solche die in den animierten PNGs im entsprechenden, oben verlinkten, Beitrag zu sehen sind, wuerde ich die Linklevel auf der Abzsisse abtragen, den Wert fuer die Grøsze von Interesse auf der Ordinate (in den bewegten Bildern ist das der Abzsisse zugeordnet), und die Anzahl der Seiten die diesen Wert haben waere dann farbcodiert (in den bewegten Bildern ist’s auf der Ordinate abgetragen).
Und hier schlaegt das erste Problem zu, denn Heatmaps wollen im Wesentlichen Pixel mit gleicher Grøsze (in eine gewaehlte Richtung).

Wenn ich die Daten einfach so in die Heatmap „reinknalle“, dann wird das zu viel. Nicht vom rechentechnischen Aufwand, aber sobald es mehr als … ich sag jetzt mal 200 Werte sind, werden die Pixel zu klein. Und hier gab es oft Verteilungen mit deutlich (!) mehr als 200 (gar bis zu ueber 5 Millionen) Werten. Und selbst wenn das fuer nur ein paar Linklevel (als „Zeitabschnitte“) der Fall ist, so sind die Millionen von Pixel bei allen anderen Linkleveln ja doch in der Heatmap vorhanden — auch wenn die „leer“ sind, so nehmen die ja doch Raum ein. Wie oben erwaenhnt, helfen einem logarithmische Achsen aus dem Dilemma, aber nur bei normalen Diagrammen.

Ich hab das mit unterschiedlich groszen Pixeln probiert (in Form einer logarithmischen Ordinate) … (keine) lange Rede, kurzer Sinn: es sieht scheisze aus, macht eine Heatmap noch schwerer zu verstehen und vermindert den groszen Vorteil einer solchen Darstellung betraechtlich — dass man auf einen Blick alles Wesentliche wahrnimmt, oder schøner ausgedrueckt mittels eines Zitats aus der Wikipedia:

[d]iese Visualisierung [Heatmaps] dient dazu, in einer großen Datenmenge intuitiv und schnell einen Überblick zu geben und besonders markante Werte leicht erkennbar zu machen.

Die letzten beiden Probleme kommen dadurch zustande, die grøszere Pixel unnatuerlich viel Raum in der Wahrnehmung einnehmen und dadurch hervorstechen … aber eigtl. sind die gar nix Besonderes … es ist aber unheimlich schwer diese (unterbewusste) Interpretation der „erhøhten Wichtigkeit“ wahrhaftig zu unterdruecken … und deswegen hab ich das hier nie gezeigt.

Das sehr spezifische Problem liegt also darin, dass ich eine „zeitartige“ Entwicklung der Verteilung einer Grøsze, deren Werte sich ueber mehrere Grøszenordnungen erstreckt, vollstaendig in nur EINEM grafischen Objekt unterbringen møchte.

Das „EINE Objekt“ in Verindung mit „vollstaendig“ laeszt nur Heatmaps zu. Die Verteilung ueber mehrere Grøszenordnungen wird mittels logarithmisch, unterschiedlich grosze Werteeimer hantiert … aber es muss eine weitere Abstraktion hinzukommen … die Details dazu beim naechsten Mal.

Wie beim letzten Mal angekuendigt, werden heute die Archipele reproduziert … øhm … das war ’n Spoiler.

Damals bin ich ueber dieses Phaenomen eher zufaellig gestolpert und habe ’ne ganze Menge draus gemacht. Heute schau ich mir nur das Gesamtergebniss an und gehe nicht nochmal auf das ein, was mich vor so vielen Beitraegen auf die Spur der Archipele brachte (zur Erinnerung (auch wenn das hier irrelevant ist): der erste Balken im hier zu sehenden Diagramm war zu hoch und das musste erklaert werden).

Natuerlich hab ich das Programm mit dem ich damals die Archipelseiten fand nochmal neu geschrieben. Die Verbindung zur Summe ueber alle Linklevel (cf. der letzte Beitrag) hatte ich ja erst nach den Archipelen entdeckt. Und OMG war das nøtig! Da drin steckte naemlich so viel was zum urspruenglichen Zweck der Untersuchungen (der Ursprung des zu hohen Balkens) beitragen sollte … und so viel Spaghetticode Experimentalcode in dem Zeilen an Stellen auszukommentieren waren, um andere Sachen an anderen Stellen anders zu bewirken.
Wieauchimmer, das ist jetzt ein feines, rekursives Programm, was ich so auch anderen Leuten zeigen kann … zugegeben, rekursiv war es notwendigerweise auch schon vorher … aber das haett ich keinem zeigen wollen.

Und hier ist das einzige Resultat von Interesse — das Histogramm bzgl. der Grøsze der Archipele der 2020- und 2023-Daten:

Zunaechst ist zu sagen, dass die Anzahl der Archipelagoseiten sich von 481.522 auf 428.315 reduziert hat. Das ist eine Reduktion um 11 % und das find ich schon signifikant. Insbesondere in Anbetracht dessen, dass die Wikipedia deutlich gewachsen ist; das ergibt also eine noch grøszere relative Reduktion.
Die Anzahl der Seiten die ein „Archipel“ nur aus sich selbst bilden reduzierte sich von 321.161 auf 297.798. Alle anderen Seiten befinden sich in Archipelen die mehr als eine Seite enthalten und davon gibt es in den 2020-Daten 21.073 und in den 2023-Daten 19.722 … deren Grøszeverteilung sieht man in den beiden Diagrammen.

Trotz des doch deutlichen Unterschieds in der Anzahl der Archipelseiten, ist die „Dynamik“ im Wesentlichen die Gleiche. Im ueblichen, doppellogarithmischen Diagramm sieht man keinen signifikaten Unterschied zwischen den beiden Datensaetzen. Bei der kumulativen Darstellung hingegen durchaus. Im mittleren Bereich weichen die 2023-Daten etwas nach oben ab. Das ist ja interessant … da sind also ’n paar grøszere Archipele noch ein bisschen gewachsen … oder neue Archipele mit aehnlicher Grøsze sind dazu gekommen. Aber wer im Detail wissen will was da passiert ist, der sollte das selber untersuchen.

Damals hatte ich mir dann auch noch zwei lange Ketten von „Inselspruengen“ angeschaut. Das hab ich auch nochmal neu programmiert (auch rekursiv), aber dieses Mal mit dem Ziel die laengsten møglichen Ketten von Spruengen zwischen „Inseln“ (vulgo: Seiten) eines Archipels zu finden (ohne auf bereits besuchte Inseln zurueck springen zu muessen). Das ist auch ein rekursiver Prozess … und nach vielen Tagen und Naechten sind bei den 2020-Daten drei, und bei den 2023-Daten zwei Archipele immer noch nicht vollstaendig nach der laengsten Ketten von Spruengen durchsucht. Auf die mathematischen bzw. programmatischen Gruende dafuer geh ich hier nicht naeher ein. Mein Bauchgefuehl sagt mir aber, dass das nicht viel ausmachen sollte und die soweit gefundenen laengsten Ketten von Spruengen mindestens die zweitlaengsten Ketten sind.

In den 2020-Daten besteht die laengste (gefundene) Kette aus 61 Spruengen, auf einem aus 88 Seiten bestehenden Archipel,
Angefangen bei der Seite List of artists with the most UK top-ten albums, welche dann die Seite Lists of UK top-ten albums zitiert, welche dann die Seite List of UK top-ten albums in 2020 zitiert, welche dann die Seite List of UK top-ten albums in 2020 zitiert, welche dann die Seite List of UK top-ten albums in 2018 zitiert, welche dann … … … die Seite List of UK top-ten albums in 1962 zitiert und dann gibt’s nichts mehr wo man hinspringen kønnte, wo man noch nicht war (auszer raus aus dem Archipel, ins grosze weite Wikipedia Linknetzwerk).

Obacht, bitte nicht vergessen: Archipelseiten werden nicht dadurch definiert, dass sie nix anderes zitieren, sondern dass sie aus dem groszen weiten Wikipedianetzwerk nicht zitiert werden (sondern allerhøchstens von anderen Archipelseiten).
Ebenso nicht vergessen: es darf nicht zurueckgesprungen werden bei diesem Spiel. Bspw. finden sich auf der Lists of UK top-ten albums Seite bereits alle Jahre, aber weil ich nicht zurueck darf, muss ich danach jedes Jahr nacheinander „anspringen“.

Bei den 2023-Daten … ist das immer noch die laengste Kette, nur dass dort dann 6 zusaetzliche Spruenge (zu drei spaeteren und 5 frueheren Jahren, bei gleichzeitigem Herausnehmen der ersten beiden Seiten der 2020-Kette) dazukommen.

Die damals erkannte Jahreskette der Waterford Senior Hurling Championship ist uebrigens weiterhin die zweitlaengste Kette, sowohl in den 2020-Daten (39 Spruenge), als auch in den 2023-Daten (46 Spruenge).
Damals hatte ich die aber entdeckt, weil diese Jahreskette wirklich nur eine lange Kette von Spruengen von Insel zu Insel ist, waehrend die Jahre der UK top-ten albums sich vermutlich untereinander zitieren.
Oder anders: Letzteres sind eher ein „Knaeuel“ als eine Kette und mein Algorithmus springt die Inseln nur bestmøglich ab. Deswegen wurde ich damals auf die Hurling Championship Jahreskette aufmerksam, einfach weil die leichter zu erkennen war.

So … das soll nun aber reichen. … Ach ja … Archipele erfolgreich reproduziert :)

Damals wurde mir ziemlich spaet erst bewusst, dass ich zwar fuer ein gegebenes Linklevel (und eine gegebene Grøsze von Interesse) die Summe ueber alle Seiten untersucht hatte, es mir bis dahin aber nie in den Sinn gekommen ist, mir mal die Summe ueber alle Linklevel einer gegebene Seite (und einer gegebenen Grøsze von Interesse) anzuschauen. Eine einzelne Summe ist natuerlich nicht von Interesse, aber die Verteilung aller Summenwerte aller Seiten schon.

Das hab ich nochmal gemacht und hier sieht man den Vergleich dieser Verteilungen bzgl. der totalen Links fuer die 2020-Daten und die 2023 Daten:

Bei doppellogarithmischer Darstellung (linkes Diagramm) sieht das gleich aus. Bei linearer Abzsisse sind die „Balken“ bei hohen Summenwerten gewaltig verschoben. Der Grund liegt natuerlich mal wieder daran, weil die 2023 Wikipedia mehr Seiten enthaelt.
Bereits damals hatte ich mir besagten „Balken“ genauer angeschaut und es stellte sich heraus, dass das gar kein Balken ist. In diesem Diagramm …

… hab ich nicht nur in die „Balken“ „reingezoomt“, sondern auch den 2023-Daten eine von den 2020-Daten unabhaengige Abzsisse gegeben (die obere). Das sieht dann wie eine „Verschiebung“ aus und erleichtert den Vergleich der Daten. Siehe da: die „Dynamik“ ist die Gleiche (gar die Selbe wuerd ich sagen), sowohl bei kleinen, als auch bei hohen Summwerten.

Obacht: bei den hohen Summen handelt es sich um weniger als 2000 Datenpunkte, die nicht mal 10 % aller Wikipediaseiten repraesentieren! Wie zu erwarten ist, haben die allerallerallermeisten Seiten die selbe Anzahl an totalen Links (das ist der eine Datenpunkt, welcher der oberen Abzsisse am naehsten kommt). Das besprach ich damals detailliert (siehe der Beitrag hinter dem obigen Link) und werde das an dieser Stelle nicht nochmal wiederholen.

Fuer die neuen Links hatte ich mir das damals nie angeschaut, aber da gibt es keine Ueberraschungen (wenn man sich schonmal die totalen Links angeschaut hat):

Die „Dynamik“ bei hohen Summenwerten scheint (deutlich?) schneller runter zu gehen als bei den totalen Links und das sollte vielleicht mal wer anders genauer untersuchen. Wie schon oben, gibt es auch hier wieder keinen echten Unterschied zwischen den beiden Datensaetzen.

Ebenso nicht angeschaut hatte ich mir die Verteilung der Summe(n) ueber die Linklevel fuer die Selbstreferenzen. Die sind hier im linken Diagramm zu sehen:

Høh? Das sieht ja (fast) so aus wie die Summer ueber alle Seiten auf einem gegebenen niedrigen Linklevel (siehe bspw. hier). Das stimmt, das sieht so aus, aber wenn man sich das mal genauer anschaut, dann ist dem nicht so. Die Aehnlichkeit kommt durch die starke „Begrenztheit“ der Selbstreferenzen zustande. Zum Einen gibt es ohnehin nicht sehr viele Selbstreferenzen und zum Anderen nimmt das „Selbstreferenzensignal“ sehr schnell ab. Ab LL₂₃ ist da (fast) nix mehr (man kønnte argumentieren, dass ab LL₁₀ praktisch nix mehr ist. Im Gegensatz zu den totalen (oder neuen) Links wo das Signal immer irgendwie hoch-ish ist, dominiert fuer diese Summe bei den Selbstreferenzen das Signal der ersten paar Linklevels und deswegen sehen sich die Verteilungen dieser zwei, konzeptionell vøllig unterschiedlichen (!), Summen so aehnlich.

Ansonsten ist nur zu sagen, dass die 2023-Daten den 2020-Daten so aehnlich sind, dass man beinahe von „deckungsgleich“ sprechen kønnte.

Als Letztes ist dann die Verteilung dieser Summenwerte fuer die Linkfrequenz im rechten Diagramm zu sehen. Das war damals der „Aufhaenger“, wie ich auf diese (andere) Summer ueberhaupt erst aufmerksam geworden bin, weil man damit ganz leicht „Archipelagoseiten“ identifizieren kann.
Wie man sieht, reproduzieren auch hier die 2023-Daten die 2020-Daten … mehr hatte ich damals dazu gesagt, was ich hier aber nicht wiederholen werde.

Beim naechsten Mal: die „Archipelagos“ an sich.

Ich wollte doch eigentlich die Simulation der Entwicklung der Selbstreferenzen von einem Linklevel zum naechsten NICHT nochmal schreiben. Ich frage mich, warum ich solche Sachen immer noch behaupte? Am Ende mach ich’s doch sowieso.
Ein Grund fuer die Meinungsaenderung waren die zwei Programme, die mir grosze Teile der Diagrammerstellung abnehmen. Das reduzierte die „Hemmschwelle“ deutlich. Der andere Grund war, dass ich den zugehørigen Code dann doch ordentlich machen wollte … ein Projekt ordentlich abzuschlieszen (auch wenn das bei diesem Projekt dauert und dauert und dauert und dauert …) motiviert mich gewaltig, auch nicht ganz so spannende Sachen gruendlich zu machen.

Wieauchimmer, ich habe das dazu gehørende Programm nochmal neu geschrieben und dabei „entruempelt“. Letzteres bezieht sich vor allem auf den Anfangszustand, von dem die Simulation starten soll.
Damals hatte ich mir dazu viele Gedanken gemacht und mehr oder weniger viel (aber sicher unnøtig) komplexen Code geschrieben. So richtig zufrieden war ich damit nicht, denn mein Ansatz fuehlte sich zu sehr ad hoc an (was erstmal nicht schlimm ist), und gleichzeitig nicht aus „einem Guss“. Beides zusammen ist schon „schlimmer“, denn das heiszt im Prinzip, dass sich ein beliebiger anderer Ansatz haette „vom Haken“ nehmen lassen.
Auszerdem løste der Ansatz das Randproblem der „wenige Daten im langen Schwanz“ auch nicht, was sich dann natuerlich durch alle Simulationsergebnisse zog.

Die erste grosze Neuerung im neuen Code ist jetzt, dass ich einfach das erste passende „Messergebnis“ als Ausgangspunkt nehme. Das løst alle oben genannten Probleme auf einen Schlag.

Die zweite grosze Neuerung ist, dass ich jetzt fuer jede „Seite“ einzeln simuliere (vulgo: zufaellig zuordne), wieviele Selbstreferenzen die auf dem naechsten Linklevel hat. Vorher hatte ich das anteilsweise fest zugeteilt.

Am Ende habe ich das dann mit den selben relevanten Parametern und den 2020 Daten (NICHT die 2023 Daten, deswegen in dem Sinne KEINE Reproduktion) alles nochmal simuliert und das ist das Ergebnis:

Die blauen Punkte sind die Ergebnisse der neuen Simulation, die roten Quadrate sind die Resultate der alten Simulation, und die grauen Diamanten sind die 2020 „Messergebnisse“. Man sieht (hoffe ich, wenn nicht schaue man sich die originalen Artikel nochmal an), dass der lange Schwanz bei den blauen Punkten nicht mehr abgeschnitten wird. Damit „passt“ das diesbezueglich deutlich besser zu den „Messergebnissen“ als die alte Simulation.

Andernfalls sind die alte und die neue Simulation gleich in allen wichtigen Punkten — Amplitude und (zunehmender) Anstieg — und teilen auch die bereits damals diskutierten Unzulaenglichkeiten.

Da es nicht Ziel dieser „Uebung“ war alles besser zu machen, bin ich sehr zufrieden und froh, dass das jetzt auch endlich fertig ist.

Zur Simulation der Selbstreferenzen via „atomistischer Naeherung“ (die ich an sich eigtl. nicht nochmal machen will, weil ich das Gefuehl hatte, dass das nicht viel gebracht hat) benøtigte ich auch die Abhaengigkeit der Anzahl der Selbstreferenzen die eine Seite auf einem gegebenen Linklevel hat, von der Anzahl der Selbstreferenzen dieser Seite auf dem vorherigen Linklevel. Oder anders und an einem konkreten Beispiel: hat eine Seite mit vielen Selbstreferenzen auf LL₅ auch viele Selbstreferenzen auf LL₆?

Nachdem ich das „Konzept“ „entwickelt“ hatte, wandte ich das dann auch auf  die totalen und neuen Links und die Linkfrequenz an. Viel ist dabei nicht rumgekommen … aber ich habe den Code dafuer neu geschrieben und deshalb liegen die Ergebnisse jetzt auch fuer die 2023 Daten vor.
Hinzu kommt, dass ich fuer’s letzte und vorletzte Mal ein Werkzeug schrieb, mit welchem ich ([deutlich mehr als] halb-)automatisiert Diagramme erstellen und schøn machen kann. Anstatt also nur ein paar repraesentative Beispiele zu zeigen, kann ich nun ohne all zu viel arbeite ALLES diagrammisieren … was in diesem Falle hiesz, deutlich ueber 200 Bilder zu erstellen. Zugegeben, die meisten davon sind nur „Zwischenschritte“ im automatischen Prozess und nicht direkt im Endergebnis zu sehen … aber erstellt werden mussten die trotzdem. Das Endergebnis sind dann nur vier bewegte Bilder; eins pro Messgrøsze. Die enthalten jeweils zwei Diagramme („Rohdaten“ und Durschnittswerte … macht schonmal acht Diagramme) und laufen ueber jedes Linklevel. Bei ungefaehr 80 zu zeigenden Linkleveln macht das ueber 600 Bilder die ihr, meine lieben Leserinnen und Leser gleich sehen werdet.

Ich schreibe das hier nochmal ausfuehrlich, weil es so ein schønes Beispiel fuer einen wichtigen Teil des wissenschaftlichen Prozesses ist: hier habe ich keine „neue“ Methode entwickelt, sondern ein effektives Werkzeug geschaffen, mit dem man viel mehr abstrakte Daten (in der Form langer Zahlenreihen) in verstaendlichere Information (in Form von „bewegten“ Diagrammen) bringen kann. Das aendert nichts an den urspruenglichen Schlussfolgerungen und Ergebnissen, erøffnet aber die „Dynamik“ eines Systems im Detail zu untersuchen … was ich aber nicht mehr machen werden.

Damit genug der langen Vorrede. Hier ist die Entwicklung der totalen Links auf einem gegebenen Linklevel in Abhaengigkeit der totalen Links auf dem vorherigen Linklevel dargestellt:

Im linken Diagramm sind die „Rohdaten“ zu sehen. Im Wesentlichen entspricht jeder Punkt einer Seite … und hier geht’s auch schon los. Nicht nur wird einem gegebenen Wert auf der Abzsisse oft mehr als einen Wert auf der Ordinate zugeordnet. Viele (in spaeteren Linkleveln alle) zu sehende Datenpunkte sind „degeneriert“. Das heiszt, dass mehrere (viele) Seiten das selbe (Anzahl-Links-auf-LL_i-1, Anzahl-Links-auf-LL_i)-Paar haben. Ich komme darauf gleich nochmal zurueck.

Desweiteren ist zu sagen, dass ich alle „Nullwerte“ weglasse. Also alle Daten die entweder keine (in diesem Fall) Links auf diesem oder dem vorherigen Level hatten. Ersters entspricht einem „Nullwert“ auf der Abzsisse, Letzteres einem „Nullwert“ auf der Ordinate. Bei den totalen Links kann Letzteres nur in der Form einer „Doppelnull“ auftreten (deswegen ist das allerletzte Diagramm auf LL₈₄ leer), aber bei den Selbstreferenzen weiter unten sind beide Faelle møglich.
Ich habe mich zu diesem Schritt aus der Not heraus entschlossen, denn die Nullen bei logarithmischen Achsen mit reinzubringen ist in der Kombination meines Diagrammerstell- und Diagrammschønmachprogramms ziemlich umstaendlich. Das ist der wirkliche Grund. Ich kønnte natuerlich auch darauf zeigen, dass die Achsen bei einem Wert von jeweils 0.5 aufhøren und ein Wert von Null darunter liegt … aber das hat mich frueher ja auch nicht gestørt … als noch keine drei Grøszenordnungen weniger Diagramme zu erstellen waren.

Beim rechten Diagramm sieht man den Durchschnittswert der totalen Links zu einem gegebenen Wert auf der Abzisse. Ein Beispiel: die (totalen) Links ALLER Seiten die auf LL₂₃ fuenf Links haben werden aufsummiert und das wird durch die Anzahl dieser Seiten dividiert. Die dabei entstehende Zahl wird im Diagramm fuer LL₂₄ genommen und auf der Abzsisse ueber dem Wert fuenf als Punkt dargestellt. Wichtig: auch die „Nullwerte“ zaehlen dazu, zwar nicht wenn die Summe gebildet wird (plus Null macht ja nix) aber sehr wohl bei der Anzahl der Seiten durch die dividiert werden muss.

Das Feine ist nun, dass damit (zwangslaeufig) jedem Wert auf der Abzsisse nur ein Wert auf der Ordinate zugeordnet wird. Auszerdem gibt es (zwanslaeufig) auch keine „degenerierten“ Punkte mehr im Diagramm.

Als naechstes das gleiche fuer die Anzahl der neuen Links:

Die Achsen reichen nicht so lang (war zu erwarten) und zum Ende hin Ende zappelts nicht mehr so doll, ja steht gar still (war auch zu erwarten, wg. der „Ketten“). Kurios ist die „Verzweigung“ zwischen LL₇ und LL₁₀. Ich weise da aber nur drauf hin, ich habe das nicht weiter untersucht und werde es auch nicht tun. Das ist aber ein schønes Beispiel fuer den oben erwaehnten Prozess, dass man mittels neuer Werkzeuge (bspw.) die „Dynamik“ eines Systems besser untersuchen kann. Das ist beim Zeigen repraesentativer Datensaetze nicht aufgetaucht (denn es ist definitiv nicht repraesentativ), aber gleichzeitig aendert es auch nichts an den wesentlichen Aussagen.

Wieder gilt: die 2023-Daten reproduzieren die 2020-Daten gut.

Auf zu den Selbstreferenzen:

Hier wird im rechten Diagramm wichtig, was ich oben zu den „Nullwerten“ sagte … und dass die Grenze eigtl. schon bei 0.5 liegt. Denn hier sieht man øfter Punkte die gerade so ueber der Abzsisse „herumduempeln“, weil die einem Durchschnittswert von gerade mal ein kleines bisschen ueber 0.5 Selbstreferenzen entsprechen. Man sieht nicht, dass manchmal einige Punkte auch unter dem Wert von 0.5 liegen … denn die werden ja „unterdrueckt“.
Oben bei den neuen Links sieht man aber einen Hinweis auf die unterdrueckten Punkte „indirekt“, wenn man ganz schnell hinschaut. Denn das LL₈₀ Durchschnittsdiagramm ist leer (die Rohdaten sind aber noch zu sehen); das erklaert sich natuerlich aus dem eben Gesagten.

Mehr gibt’s nicht zu sagen … ach doch: und nocheinmal reproduzieren die 2023-Daten die 2020-Daten gut.

Als Letztes dann die Linkfrequenz:

Auch wenn ab ca. LL₁₅ deutlicher als bei den anderen Diagrammen zu sehen ist, dass die schwarzen und roten Punkte nicht mehr (beinahe) deckungsgleich sind, so bleiben alle Merkmale (Form, Verlauf und „Merkwuerdigkeiten“) erhalten. Deswegen bleibt mir nix weiter als zu sagen: auch hier ist die Reproduktion der 2020-Daten in den 2023-Daten gelungen.

Ach doch, eine Sache noch: waehrend der Durchschnittswert fuer die Links und Selbstreferenzen durchaus sinnvoll ist, gilt das fuer die Linkfrequenz mitnichten. Da kommt einfach keine (mehr oder weniger) gerade Linie bei raus, sondern die Ellipse bleibt bestehen. Man muss also immer die Sinnhaftigkeit und Interpretation der angewandten (nicht notwendigerweise nur mathematischen) „Umformungen“ der Daten gut durchdenken, damit man keinen Mist publiziert.

Und damit soll’s gut sein damit. Etwas wehmuetig habe ich das alles in nur einen Beitrag gepackt. Wehmuetig deswegen, weil trotz der (mehr oder weniger) automatisierten Bilderstellung, es noch fast ’ne Woche dauerte bis die hier zu sehenden Endresultate fertig waren … und die ganze Arbeit ist mit nur einem Beitrag „abgegessen“ … Uff! … Aber letztlich gibt’s nicht wirklich viel mehr dazu zu sagen und das ist auch gut so, denn um es muss noch mehr reproduziert werden … und ich will wirklich auch mal mit dem ganzen Projekt abschlieszen.

Aus der Entwicklung der Anzahl der Selbstreferenzen kam damals eins der schønsten Ergebnisse all dieser Untersuchungen heraus (die Verbildlichung des Sprichworts „vom Hundertsten ins Tausendste kommen“). Das muesste ich eigentlich nicht nochmal machen, denn beim letzten Mal zeigte sich ja, dass die entsprechen Daten aus 2019 und 2023 uebereinander liegen und somit die selben Anstiege haben (es wuerde also eine Art „Autoreproduktion“ vorliegen).

Besagte Anstiege wurden aus doppellogarithmischen Plots „herausgezogen“ … die waren aber (noch) nicht kumulativ, denn da bin ich erst spaeter drauf gekommen. Bei dem spaeter hatte ich das dann zwar nochmal kurz angeschaut, aber nur qualititativ (vulgo: draufgucken ob das richtig aussieht) und nicht quantitativ.

Das aendert nix daran, dass ich das nicht nochmal machen muesste … aber ich hab mir nun ein Programm geschrieben, welches kumulative log-log Diagramme automatisch erstellt und mittels linearer Regression anpasst … mit dem feinen Zusatz, dass dieses Programm erlaubt, vorne und hinten Punkte „abzuschneiden“ (weil die manchmal Aerger machen) und das dann mit den Originaldaten direkt verglichen werden kann.
Oder anders: ich hatte den kumulativen Teil vorher immer manuell gemacht und das dauert ’ne Weile wenn man das fuer viele Datensaetze machen muss. Ebenso ist es zeitaufwaendig „Aerger machende Punkte am Anfang und Ende“ zu entfernen und jedes Mal die lineare Regression durchzufuehren. Das waren die Gruende, warum ich das damals dann nur nochmal qualitativ anschaute. Aber all das ist jetzt VIIIIIIEEEEL schneller … und deswegen hab ich das jetzt doch nochmal quantitativ-isiert:

Weil die 2019 und 2023 Daten hierfuer uebereinander liegen, vergleiche ich in dem Bild natuerlich nicht die, sondern was Anderes. Naemlich die urspruenglichen Anstiege der linearen Regression, ermittelt aus NICHT kumulativen log-log Diagrammen und die Anstiege die ich mittels des besagten (kumulativen) Programms bekommen habe.

Im Wesentlichen stimmt das ueberein. Wobei ich den neuen Daten (aus kumulativen Plots) eher vertraue wuerde. Zur Erklaerung der Unterschiede kommen die Fehlerbalken und die „duennblauen“ Punkte ins Spiel. Aber der Reihe nach.

Erstens, „zappeln“ NICHT kumulierte Daten mehr. Insb. hin zu kleinen Haeufigkeiten (wenn also nur noch wenige Punkte zum Signal beitragen). Dieses „Zappeln“ fuehrt dann zu gewissen „Fehlerbalken“ und der wahre Wert des Anstiegs hat eine gewisse (meist 95 %) Chance innerhalb dieses Intervalls zu liegen. Wenn man die Fehlerbalken mit in Betracht zieht dann ueberlappt sich da schon recht viel.
Apropos Fehlerbalken; die Ergebnisse der linearen Regression von kumulativen Daten muessen korrigiert werden. Bei den Werten fuer den Anstieg muss man hier nur eine eins abziehen. Der Betrag des Anstiegs wird also grøszer. Das ist einfach. Ich weisz aber nicht, inwieweit die Fehlerbalken durch die Kumulierung beentraechtigt werden. Mein Bauchgefuehl und halbgares Verstaendniss der Mathematik sagt mir aber, dass die roten Fehlerbalken etwas (ich weisz nur nicht wieviel) laenger werden sollten … das wuerde dann zu noch mehr Uebereinstimmungen fuehren.

Damals musste ich auszerdem oft den (langen) „Schwanz“ der Daten in den NICHT kumulativen Plots abschneiden, denn ansonsten haette die lineare Regression nix Vernuenftiges errechnet. Diese „Grenzen“ fuer die Regression hatte ich mehr oder weniger mit dem Auge abgeschaetzt. Zum Glueck schrieb ich die konkreten Werte fuer besagte Grenzen auf (das wird gleich nochmal wichtig).
Auch bei kumulierten Daten muss man Punkte „aufgeben“ (siehe oben). Aber es muessen laengst nicht so viele Punkte „weggeschmissen“ werden. Meist weniger als ein Dutzend (oder sehr oft auch gar keine), wenn die Daten dann offensichtlich einem Potenzgesetz gehorchen. (Im Unterschied zu manchmal hunderten (!) bei nicht kumulativen Plots)

Nun gibt es in obigem Bild doch genuegend Abweichungen, dass mir das (mal wieder) keine Ruhe liesz und ich da genau hinschaute. Konkret „schnitt“ ich bei den kumulativen Plots genau so viele Punkte ab, wie damals bei den grauen Daten. Das spiegelt sich in den „duennblauen“ Punkten wieder (Fehlerbalken hab ich weggelassen). Und siehe da! Die stimmen im Wesentlichen mit den roten Punkten ueberein.
Das war beruhigend herauszufinden, denn damit lag der Fehler ja ganz eindeutig nicht bei mir. Vielmehr bedeutet dies, dass die Unterschiede im obigen Diagramm tatsaechlich auf die „Methode“ an sich (also NICHT kumulative log-log Plots und dem staerkeren „Herumzappeln“ dort) zurueckzufuehren sind, als auf das Abschaetzen der Grenzen fuer die lineare Regression. Oder anders: (bestimmt nicht nur) die grauen Fehlerbalken sollten vermutlich noch laenger sein.

So … wie gesagt, das hier ist keine Reproduktion im Sinne dessen, dass ich mir bzgl. der Daten aus unterschiedlichen Jahren anschaue … aber ’ne Art Reproduktion ist’s ja doch und weil ich da jetzt doch noch ein kleines Werkzeug zu programmiert und mir das alles nochmal „durchgerechnet“ hatte, wollte ich das hier auch aufgeschrieben haben.