Tibiasatsen — Del IV: Från Tibias flashbacks till The Flashback Theorem
I Del III blev kugghjulen källkod.
Deploy hittar ni på https://pi.gegge.se
Kalendrar reducerades till perioder och rester, CRT slog ihop de rester som kunde leva på samma dygn, och vittnen räknades fram aritmetiskt i stället för att sökas dag för dag.
Men vart tog Tibiasatsen vägen?
Tibiasatsen är mitt svenska namn för The Flashback Theorem. Den säger i grunden att en sökning bara får återanvända framtiden när den kommit tillbaka till samma framtidsrelevanta tillstånd.
Inte samma datum. Inte samma fasad. Samma regler, samma resurser och samma möjliga nästa steg.
Tänk ett spel: kommer du tillbaka till samma rum med samma nycklar, ammunition, cooldowns och fiender kvar, då är resten redan löst. Historien som tog dig dit spelar ingen roll. Skiljer något av detta sig är det däremot inte samma rum i satsens mening. Så vi tillåter källkoden försöka att själv få definiera vilka träffar som finns att söka, och se om en maskin som får nya regler också måste börja minnas.
I kalenderkärnan finns en liten statisk variant. När olika CRT-vägar ger samma kanoniska vittnesklass
behåller koden den en gång. Olika väg in, samma restklass ut, samma återstående kugghjul. Det är flashback-principen i miniatyr.² Men det är inte den fulla Tibiasatsen. Kalendern bryr sig inte om att vi hittade ett datum i går. Vittnen förbrukas inte. Ingen cooldown uppstår. Ingen frontier rörs. Ingen historik förändrar nästa sökning. Sedan gjorde jag merge-historiken till ett belöningssystem.
tar SHA, UTC-tid, antal commits, additions, deletions, lockfil, mergeföräldrar och diverse editorrelaterade olyckor. Resultatet blir ett bundet sökfönster på JDN-axeln. Ingen Git-process körs i motorn, ingen persons namn behövs och samma mergebeskrivning ger samma sökning.¹
SHA:n är fröet. Antalet commits är frekvensen:
Det är inte poäng. Det är livslängd. Fler commits ger fler varv i sökningen, inte en garanterad träff. Belöningen för en merge är alltså mer arbete.
Additions och deletions bestämmer riktningen:
Bygger du går du mot framtiden. Städar du gräver du i historien. A = 0 ger ingen riktning och sökningen voidas.
Sedan kommer fortunes. Fredag, söndag, lockfiler, merge commits, CRLF, trailing whitespace och jämnt antal commits får avgöra din kosmiska värdighet. Samtidigt premieras 03:14 och 15:14 UTC, Pi Day, onsdag 14:00, primtal antal commits och SHA:n som råkar innehålla 314. 03:14:15 UTC blir legendariskt.
Vart tog hårdheten vägen?
Den här gången vet jag exakt vart den tog vägen. Den hamnade i ett regelverk som delar ut godtyckliga bedömningar till helt vanliga merge:ar. Och när man får ett godtyckligt beräkningsproblem måste man naturligtvis svara med en godtycklig simulering. Hade de två sakerna hängt ihop hade det varit en modell, och då hade man fått börja ta ansvar för den. Rent matematiskt måste negativitet kontreras med negativitet:
Medan principalroten ur 1 blir 1, inte -1. Det motsatta ledet återställer alltså inte den negativa informationen. Slutsatsen är given: vill man få något positivt ur något negativt måste man lägga på ytterligare något negativt. Därför straffas en fredagsmerge. Inte för att den gjort fel, utan för att algebra kräver sin tribut.
En perfekt π-dag är en perfekt π-dag. Singel, dubbel och trippel är egenskaper hos dagen, inte grader av människovärde. En träff hör till commiten, inte personen bakom den. Annars får man snabbt en troféhall för inbördes beundran, och i mitt fall hade den haft en ovanligt konstant medlemslista.
The Flashback Theorem finns däremot fortfarande inte i koden i sin fulla dynamiska form. Reckoning är en ren funktion: mergefakta in, sökfönster och träffar ut. Resultatet från merge n förändrar inte merge n + 1. Det finns ingen frontier, ingen cooldown, ingen återstående resurs och ingen cykelanalys över ett tillståndsrum. Det är därför satsen saknas. Inte för att den glömdes, utan för att den vore fel sats för ett system där historiken ännu inte ändrar framtiden.
Frö är inte minne
Det finns en skillnad som är lätt att missa eftersom båda råkar använda det förflutna. SHA:n är ett frö. Den beskriver var en enskild sökning ska börja, men den minns inget från den föregående sökningen. Den ger variation mellan merge:ar utan att någon merge lämnar ett spelstate efter sig. En cooldown gör motsatsen: den säger att det som hände nyss begränsar vad som får hända sedan. En frontier gör samma sak: den gör nästa steg beroende av hur långt man redan har kommit.
Det är alltså inte nog att programmet läser historiska fakta. Ett bankutdrag är inte ett bankkonto bara för att båda nämner pengar. För att Tibiasatsen ska bli relevant måste utfallet från den gamla körningen vara en del av indata till den nya. Först då kan två olika historier kollapsa till samma state. Först då blir det meningsfullt att leta efter en cykel i stället för att bara köra samma rena funktion igen med andra argument.
Det gör också den nuvarande begränsningen till en fördel. Reckoning använder mergehistoriken som kryptiskt väder, inte som kausalitet. SHA:n placerar fönstret. Additions och deletions väljer riktning. Fortunes förvränger räckvidden. Men inget av detta ger en commit rätt att påverka nästa commits öde. Maskinen är därför rättvis på det tråkigaste möjliga sättet: den behandlar varje merge som en isolerad naturkatastrof.
Den verkliga hårdheten
I Del III flyttades hårdheten från tidsaxeln till restgeometrin. Här flyttas den igen, men inte till datorn. Själva Reckoning-sökningen är billig eftersom den arbetar med redan kompilerade perioder och vittnen. Den svåra delen är att avgöra vilka detaljer som ska få följa med in i framtiden. Räcker SHA, riktning och frekvens? Ska en fångad dag tas ur kartan? Ska en bot-merge räknas? Återställs en cooldown vid ny regelbok eller lever den för evigt?
Varje sådant beslut är en ny koordinat i tillståndet. Glömmer man en koordinat får man en falsk flashback: två lägen ser lika ut, men har olika framtid. Lägger man till för många blir staten så detaljerad att ingenting någonsin återkommer. Tibiasatsen är därför mindre en belöning för att ha hittat en cykel än ett hot om att man måste kunna förklara exakt vad man har glömt.
Append-only är inte dekor
Det är också därför regelboken måste vara append-only. Om en ny kalender, datumordning eller belöningsregel läggs till ändras vilka framtider som över huvud taget är möjliga. Då är det inte längre samma spelstate, hur gärna man än vill återanvända gamla träffar. Den korrekta flashbacken är inte “samma SHA” eller “samma datum” utan samma state under samma regelbok.
Det är en hög ribba. Men den är mindre godtycklig än att först döma två saker som lika, sedan hävda att deras olika framtider ändå saknar betydelse. Här får godtycket åtminstone ett versionsnummer.
Sidan har också fått en viktig korrigering. JDN är den egentliga axeln: samma absoluta dygn. Kalendrar är olika namn på den axeln. Det gregorianska datumet är nu ett synligt ankare, medan en juliansk träff visar sin egen läsning:
Gregorian är för närvarande låst som presentationsankare, men ankaret är inte sanningen. JDN är sanningen. Gregorian är bara den kalender som får stå bredvid och förklara sig.³
Det finns en viss tröst i att regelboken åtminstone blir append-only. Den får gärna vara hård, absurd och full av negativa multiplikatorer, men den ska inte behöva räkna bokstäver för att avgöra om två saker är samma. Den behöver bara avgöra om framtiden faktiskt skiljer sig. Är tillståndet detsamma, är också domen densamma. Allt annat är bara administrativ restgeometri.
Det blir nästan komiskt hur jag försökte tackla problemet genom att skapa en sökrymd via den anekdot som gav upphov till Tibiasatsen, och därmed göra det oändliga mer hanterbart. I efterhand vet vi att Tibiasatsen använder sig utav minne för att spirala i sin sökrymd. Sökrymden får inte vara oändlig. Under tiden låter jag min Raspberry Pi med Pi fortsätta i all oändlighet att söka efter dagar som råkar sammanfalla på pi. Svaret på problemet är att göra minnet till något som är tillbakablickande. Så här skriver jag på Flashback om mina flashbacks genom att göra flashback till ren jävla matematik.
Referenser
¹ Reckoning-kärnan vid commit 1f77a11 och fortunes vid samma commit
² CRT och deduplicering vid commit 1f77a11
³ JDN-ankare och kalenderns egen läsning vid commit 1f77a11
Deploy hittar ni på https://pi.gegge.se
Kalendrar reducerades till perioder och rester, CRT slog ihop de rester som kunde leva på samma dygn, och vittnen räknades fram aritmetiskt i stället för att sökas dag för dag.
Men vart tog Tibiasatsen vägen?
Tibiasatsen är mitt svenska namn för The Flashback Theorem. Den säger i grunden att en sökning bara får återanvända framtiden när den kommit tillbaka till samma framtidsrelevanta tillstånd.
Kod:
samma framtidsrelevanta tillstånd = samma möjliga framtid = ingen ny lösning behövs
Inte samma datum. Inte samma fasad. Samma regler, samma resurser och samma möjliga nästa steg.
Tänk ett spel: kommer du tillbaka till samma rum med samma nycklar, ammunition, cooldowns och fiender kvar, då är resten redan löst. Historien som tog dig dit spelar ingen roll. Skiljer något av detta sig är det däremot inte samma rum i satsens mening. Så vi tillåter källkoden försöka att själv få definiera vilka träffar som finns att söka, och se om en maskin som får nya regler också måste börja minnas.
I kalenderkärnan finns en liten statisk variant. När olika CRT-vägar ger samma kanoniska vittnesklass
Kod:
t ≡ residue (mod modulus)
behåller koden den en gång. Olika väg in, samma restklass ut, samma återstående kugghjul. Det är flashback-principen i miniatyr.² Men det är inte den fulla Tibiasatsen. Kalendern bryr sig inte om att vi hittade ett datum i går. Vittnen förbrukas inte. Ingen cooldown uppstår. Ingen frontier rörs. Ingen historik förändrar nästa sökning. Sedan gjorde jag merge-historiken till ett belöningssystem.
Kod:
reckon()
tar SHA, UTC-tid, antal commits, additions, deletions, lockfil, mergeföräldrar och diverse editorrelaterade olyckor. Resultatet blir ett bundet sökfönster på JDN-axeln. Ingen Git-process körs i motorn, ingen persons namn behövs och samma mergebeskrivning ger samma sökning.¹
SHA:n är fröet. Antalet commits är frekvensen:
Kod:
f = clamp(commits, 1, 124)
Det är inte poäng. Det är livslängd. Fler commits ger fler varv i sökningen, inte en garanterad träff. Belöningen för en merge är alltså mer arbete.
Additions och deletions bestämmer riktningen:
Kod:
D < 0.1 · A → AD D ≥ 0.1 · A → BC
Bygger du går du mot framtiden. Städar du gräver du i historien. A = 0 ger ingen riktning och sökningen voidas.
Sedan kommer fortunes. Fredag, söndag, lockfiler, merge commits, CRLF, trailing whitespace och jämnt antal commits får avgöra din kosmiska värdighet. Samtidigt premieras 03:14 och 15:14 UTC, Pi Day, onsdag 14:00, primtal antal commits och SHA:n som råkar innehålla 314. 03:14:15 UTC blir legendariskt.
Kod:
f' = clamp(round(f · produkt(av fortunes)), 0, 124)
Vart tog hårdheten vägen?
Den här gången vet jag exakt vart den tog vägen. Den hamnade i ett regelverk som delar ut godtyckliga bedömningar till helt vanliga merge:ar. Och när man får ett godtyckligt beräkningsproblem måste man naturligtvis svara med en godtycklig simulering. Hade de två sakerna hängt ihop hade det varit en modell, och då hade man fått börja ta ansvar för den. Rent matematiskt måste negativitet kontreras med negativitet:
Kod:
(-1)² = 1
Medan principalroten ur 1 blir 1, inte -1. Det motsatta ledet återställer alltså inte den negativa informationen. Slutsatsen är given: vill man få något positivt ur något negativt måste man lägga på ytterligare något negativt. Därför straffas en fredagsmerge. Inte för att den gjort fel, utan för att algebra kräver sin tribut.
En perfekt π-dag är en perfekt π-dag. Singel, dubbel och trippel är egenskaper hos dagen, inte grader av människovärde. En träff hör till commiten, inte personen bakom den. Annars får man snabbt en troféhall för inbördes beundran, och i mitt fall hade den haft en ovanligt konstant medlemslista.
The Flashback Theorem finns däremot fortfarande inte i koden i sin fulla dynamiska form. Reckoning är en ren funktion: mergefakta in, sökfönster och träffar ut. Resultatet från merge n förändrar inte merge n + 1. Det finns ingen frontier, ingen cooldown, ingen återstående resurs och ingen cykelanalys över ett tillståndsrum. Det är därför satsen saknas. Inte för att den glömdes, utan för att den vore fel sats för ett system där historiken ännu inte ändrar framtiden.
Frö är inte minne
Det finns en skillnad som är lätt att missa eftersom båda råkar använda det förflutna. SHA:n är ett frö. Den beskriver var en enskild sökning ska börja, men den minns inget från den föregående sökningen. Den ger variation mellan merge:ar utan att någon merge lämnar ett spelstate efter sig. En cooldown gör motsatsen: den säger att det som hände nyss begränsar vad som får hända sedan. En frontier gör samma sak: den gör nästa steg beroende av hur långt man redan har kommit.
Det är alltså inte nog att programmet läser historiska fakta. Ett bankutdrag är inte ett bankkonto bara för att båda nämner pengar. För att Tibiasatsen ska bli relevant måste utfallet från den gamla körningen vara en del av indata till den nya. Först då kan två olika historier kollapsa till samma state. Först då blir det meningsfullt att leta efter en cykel i stället för att bara köra samma rena funktion igen med andra argument.
Det gör också den nuvarande begränsningen till en fördel. Reckoning använder mergehistoriken som kryptiskt väder, inte som kausalitet. SHA:n placerar fönstret. Additions och deletions väljer riktning. Fortunes förvränger räckvidden. Men inget av detta ger en commit rätt att påverka nästa commits öde. Maskinen är därför rättvis på det tråkigaste möjliga sättet: den behandlar varje merge som en isolerad naturkatastrof.
Den verkliga hårdheten
I Del III flyttades hårdheten från tidsaxeln till restgeometrin. Här flyttas den igen, men inte till datorn. Själva Reckoning-sökningen är billig eftersom den arbetar med redan kompilerade perioder och vittnen. Den svåra delen är att avgöra vilka detaljer som ska få följa med in i framtiden. Räcker SHA, riktning och frekvens? Ska en fångad dag tas ur kartan? Ska en bot-merge räknas? Återställs en cooldown vid ny regelbok eller lever den för evigt?
Varje sådant beslut är en ny koordinat i tillståndet. Glömmer man en koordinat får man en falsk flashback: två lägen ser lika ut, men har olika framtid. Lägger man till för många blir staten så detaljerad att ingenting någonsin återkommer. Tibiasatsen är därför mindre en belöning för att ha hittat en cykel än ett hot om att man måste kunna förklara exakt vad man har glömt.
Append-only är inte dekor
Det är också därför regelboken måste vara append-only. Om en ny kalender, datumordning eller belöningsregel läggs till ändras vilka framtider som över huvud taget är möjliga. Då är det inte längre samma spelstate, hur gärna man än vill återanvända gamla träffar. Den korrekta flashbacken är inte “samma SHA” eller “samma datum” utan samma state under samma regelbok.
Det är en hög ribba. Men den är mindre godtycklig än att först döma två saker som lika, sedan hävda att deras olika framtider ändå saknar betydelse. Här får godtycket åtminstone ett versionsnummer.
Sidan har också fått en viktig korrigering. JDN är den egentliga axeln: samma absoluta dygn. Kalendrar är olika namn på den axeln. Det gregorianska datumet är nu ett synligt ankare, medan en juliansk träff visar sin egen läsning:
Kod:
Juliansk läsning: 2031-04-15 31 · 4 · 15 · 92653589 Samma JDN som gregorianskt: 2031-04-28
Gregorian är för närvarande låst som presentationsankare, men ankaret är inte sanningen. JDN är sanningen. Gregorian är bara den kalender som får stå bredvid och förklara sig.³
Det finns en viss tröst i att regelboken åtminstone blir append-only. Den får gärna vara hård, absurd och full av negativa multiplikatorer, men den ska inte behöva räkna bokstäver för att avgöra om två saker är samma. Den behöver bara avgöra om framtiden faktiskt skiljer sig. Är tillståndet detsamma, är också domen densamma. Allt annat är bara administrativ restgeometri.
Det blir nästan komiskt hur jag försökte tackla problemet genom att skapa en sökrymd via den anekdot som gav upphov till Tibiasatsen, och därmed göra det oändliga mer hanterbart. I efterhand vet vi att Tibiasatsen använder sig utav minne för att spirala i sin sökrymd. Sökrymden får inte vara oändlig. Under tiden låter jag min Raspberry Pi med Pi fortsätta i all oändlighet att söka efter dagar som råkar sammanfalla på pi. Svaret på problemet är att göra minnet till något som är tillbakablickande. Så här skriver jag på Flashback om mina flashbacks genom att göra flashback till ren jävla matematik.
Referenser
¹ Reckoning-kärnan vid commit 1f77a11 och fortunes vid samma commit
² CRT och deduplicering vid commit 1f77a11
³ JDN-ankare och kalenderns egen läsning vid commit 1f77a11
__________________
Senast redigerad av gason 2026-09-16 kl. 00:38. Anledning: Länkar till referenser längst ner korrigerade på begäran.
Senast redigerad av gason 2026-09-16 kl. 00:38. Anledning: Länkar till referenser längst ner korrigerade på begäran.
