AXIOM och punkten som rör sig
Punkten flyttades, kontraktet gjorde det inte
Fastpunktsaritmetik är attraktiv eftersom den är ärlig. Du väljer en skala, du anger var punkten ligger, och maskinen slutar låtsas att varje tal är en liten väderprognos. Det gör uppspelning lugnare, inbäddade mål lättare att resonera kring, och revisioner mindre beroende av fraser som ungefär. Underbart. Också ofullständigt.
En fast skala kan vara för trubbig. Välj en skala som hanterar mycket små värden och de större värdena får slut på utrymme. Välj en skala som hanterar större värden och de små värdena förlorar användbar detalj. Du kan dela upp arbetet i flera typer, men nu har kodbasen en annan sorts röra. Grattis, decimalpunkten är nu ett bemanningsproblem.
AXIOM finns för de fall där punkten behöver flyttas utan att det numeriska lagret förvandlas tillbaka till flyttalssoppa. I Dweve-kodbasen är det en adaptiv variabelpunktsfamilj: varje konkret värde bär ett tecken, ett exponentlisteindex och en mantissa i en packad 32-bitarsrepresentation. Exponenten är inte ett omgivande hårdvarustämningsläge. Den väljs från en explicit lista. Mantissan är en heltalsnyttolast. Det representerade värdet är tecken gånger mantissa gånger två upphöjt till minus den valda exponenten. Den meningen är inte söt, men den är hela tricket.
Det viktiga är inte att punkten flyttas. Flyttal flyttar redan punkten. Det viktiga är att AXIOM flyttar den genom en deklarerad lista som kan granskas, testas, specialiseras och hållas deterministisk. Koden ber inte plattformen att improvisera en numerisk personlighet. Den ger värdet ett kompakt kontrakt och får aritmetiken att återvända till det kontraktet efter varje operation.
I källkoden är den konkreta formen Axiom<M, E>. Mantissbredden måste passa representationen, med praktiska alias som Adp4, Adp8, Adp16, Adp23, AdpNN4 och AdpNN8. Dessa namn är inte dekorationer. De berättar hur mycket nyttolast och vilken exponentprofil värdet förväntas använda. Ett värde med en NN-formad exponentlista är inte samma löfte som ett värde med en bredare generell lista. Att behandla dem som samma eftersom båda ser numeriska ut är hur seriösa kodbaser börjar samla på folklore.
Variabel punkt är inte vibbar
Frasen adaptiv variabel punkt kan låta som att någon bytte namn på flyttal för att få inköp att godkänna ett möte. Det är inte vad som händer. AXIOM gör inte exponenten till en osynlig bieffekt. Exponenten väljs från en lista som är kopplad till typen eller strategin. I den aktuella källkoden inkluderar de konkreta exponentlistorna standard [16, 8, 4, 0], tät [12, 8, 4, 0], neurala nätverksvikter [8, 6, 4, 0] och en fin lista [16, 14, 12, 10, 8, 6, 4, 0]. Dessa är de aktuella källkodsvärdena, och den distinktionen spelar roll eftersom källkoden har ändrats över tid; aktuella påståenden bör följa aktuell kod, inte föråldrade exponentlistor.
Listan är produktbeslutet. En standardlista ger några få breda band. En tät lista ändrar var banden sitter. NN-listan är formad för viktliknande data. Den fina listan erbjuder fler närliggande val. Inget av detta tar bort omdöme. Det flyttar omdömet till en plats där kodgranskning kan se det.
Detta är skillnaden mellan en kontrollerad adaptiv representation och en allmän ursäkt. En fixed-point-typ säger att varje värde här använder denna skala. AXIOM säger att varje värde här väljer från denna deklarerade uppsättning skalor. Det är ett bredare kontrakt, inte ett saknat sådant. Punkten rör sig, men den rör sig på räls. Mycket holländskt, faktiskt. Även decimaltecknet har infrastruktur.
Det är värt att vara precis om vad AXIOM inte är. Det är inte exakt rationell aritmetik. Det är inte en licens att ignorera räckviddsanalys. Det är inte ett benchmark-påstående. Det är inte en garanti att den valda exponentlistan passar din arbetsbelastning bara för att akronymen såg energisk ut. Du behöver fortfarande förstå värdena, det dynamiska omfånget, den acceptabla felmarginalen, distributionsmålet och uppspelningskraven. AXIOM gör dessa val mer inspekterbara. Det får dem inte att försvinna. Om något gör det latare numeriskt tänkande svårare att dölja, vilket är vanligtvis där skriket börjar.
Aritmetiken måste komma hem
Ett talformat är lätt att rita och svårare att göra användbart. Det användbara är aritmetiken. Addition och subtraktion måste hantera värden som kan sitta på olika exponentband. Multiplikation och division måste göra bredare heltalsmantissarbete innan resultatet återförs till målformen. Efter operationen måste värdet normaliseras tillbaka till ett tillgängligt exponentval. Det sista steget spelar roll eftersom en representation som inte kan komma hem bara är en semester utomlands med bättre varumärke.
AXIOM-aritmetik har därför en rytm. Ta in packade värden. Rikta in eller bredda vid behov. Utför den heltalsorienterade operationen. Normalisera. Lagra resultatet tillbaka i den deklarerade formen. Om det inte passar ska det synas som ett representationsproblem, inte tyst delegeras till maskinens humör. Kontraktet är användbart eftersom det har kanter.
Detta är samma anledning till att Numerus spelar roll runtomkring. Den bredare stacken försöker inte samla talformat som frimärken. Den vill ha aritmetik som kan överleva uppspelning, inbäddad distribution, simulering, modellkomprimering, tester och revisionsspår. AXIOM är en familj i den berättelsen. Den hanterar ett särskilt problem: värden vars användbara skala ändras, men vars beteende fortfarande måste vara deterministiskt.
Det är den tråkiga meningen som räddar team senare: normalisera tillbaka till form. Det låter som implementeringsdetalj tills en uppspelning skiljer sig, ett tröskelvärde flippar, eller en komprimerad modell beter sig annorlunda på ett mindre mål. Då blir det meningen som alla önskar hade funnits i arkitekturdokumentet.
Varför AXIOM ligger under Numerus
Den publika Numerus-berättelsen är medvetet enklare än källträdet. De flesta läsare vill veta om det numeriska lagret kan ge deterministisk aritmetik, fixed-point-familjer, decimalbeteende, no_std-hållning, heltalsorienterade inbäddade profiler, verifiering och samma svar två gånger. De behöver inte varje intern typ på första sidan. Det är inte hemlighetsmakeri. Det är barmhärtighet.
Underneath ligger det gemensamma numeriska lagret bredare. Det bär på binära, ternära, inbyggda och sub-byte heltalstyper, fixed-point-alias, float-relaterade typer för kompatibilitetsarbete och adaptiv AXIOM. De delade traiterna ger dessa familjer en gemensam yta. Numerus omsluter sedan de delar som ska vara produktvända: binär och decimal fixed-point, AXIOM, heltal, operationer, DSL-ytor och verifieringshållning. Den här uppdelningen är sund. En grund kan vara bred utan att den publika sidan ser ut som en meny från en restaurang som tappat självförtroendet.
AXIOM förtjänar en egen artikel eftersom det inte bara är ännu en post i den listan. Fixed-point handlar om att placera punkten på en plats. Decimal fixed-point handlar om exakta bas-tio-platser. Binära och ternära former handlar om kompakta lågbitvägar. AXIOM handlar om att göra punkten till en kontrollerad del av värdet. Det förändrar hur du tänker kring representation, aritmetik, tester och driftsättning.
Det förändrar också hur publika påståenden bör avgränsas. AXIOM-prestanda tillhör aktuella riktmärken på aktuell kod, inte nedärvd folklore. Den bredare stacken bör inte beskrivas som noll flyttalsoperationer, eftersom konverterings- och visningsytor kan korsa den gränsen. Det säkrare och mer korrekta påståendet är att den grundläggande fixa och adaptiva aritmetiken är heltalsorienterad och utformad för deterministiskt beteende. Den meningen är mindre flashig. Bra. Flashiga numeriska påståenden är hur instrumentpaneler blir ursäktsgeneratorer.
Flera beräkningsvägar, en familj
Det konkreta packade värdet är bara början. Källkoden innehåller mer än ett sätt att använda AXIOM eftersom arbetsbelastningar inte är artiga nog att passa en layout för alltid. Det finns den packade konkreta vägen för kompileringstidsexponentlistor. Det finns Flex<S> för lagring av runtime-exponenter över heltalslagringsstorlekar. Det finns tensor- och blockformer där delad exponentstruktur kan vara användbar. Det finns stratifierad bearbetning. Det finns APoT, där värden kan representeras som summor av teckenförsedda tvåpotenser så att multiplikation kan bli skiftningar och additioner. Det finns profilerings- och inlärda exponentforskningskoder runt omkring.
Den spridningen är inte en anledning att komma med vilda påståenden. Den är en anledning att vara noggrann med arbetsbelastningen. En skalär replay-väg, en batchkvantiseringsväg, en tensorliknande väg och en APoT-viktväg har olika påfrestningar. Minneslayout, exponentåteranvändning, intervall, normalisering och hårdvaruform spelar alla roll. AXIOM ger ett ordförråd för dessa val. Det befriar ingen från att göra dem.
Det är här ingenjörskonsten blir intressant. APoT är inte bara ett gulligt komprimeringstrick. För lämpliga värden förvandlar det multiplikation till ett skift-och-add-problem. Tensor- och blockvägar kan dela exponentstruktur när en arbetsbelastning har tillräcklig form. Flex håller runtime-exponentlagring tillgänglig när typnivålistor är för stela. Ingen av dessa bör väljas för att diagrammet såg trevligt ut. Arbetsbelastningen väljer, annars väljer buggrapporten senare och är betydligt mindre charmig om det.
Så granskar du ett AXIOM-val
The first review question is boring and therefore useful: why not a simpler number type? If the value is money or a regulated decimal amount, Decimal may be the right answer. If the range is small and well bounded, a Q-format fixed-point type may be calmer. If the number exists only to interoperate with a file format or external API, a float-related type might be the honest edge adapter. AXIOM earns its keep when the workload has changing magnitude, still needs a deterministic contract, and benefits from an explicit exponent set.
The second question is whether the exponent list describes the data or merely flatters the engineer. A list with four broad bands is a different tradeoff from a fine-grained eight-entry list. The NN-shaped list is not a decorative label. It says the values are expected to behave like weight data. If the distribution does not match the list, the representation will still run. Software is often willing to do the wrong thing at impressive speed. That does not make it a design.
The third question is where normalization pressure appears. Addition across distant exponent bands can discard detail. Multiplication can create a result that needs a different band. Repeated operations can accumulate pressure at exactly the places the demo did not visit. The review should ask for boundary tests around zero, sign changes, exponent transitions, large mantissas, and repeated operations. If those cases feel annoying, good. They are probably the cases that matter.
The final question is how the representation leaves evidence. Which type alias did we choose? Which exponent list? Which mantissa width? Which conversion path? Which oracle or property test backs the claim? If the answer is scattered across comments and optimism, the system has already lost some of the benefit. AXIOM is most useful when the numeric choice becomes part of the architecture record, not a clever local trick hidden three modules down.
Verification beats hero numbers
Numerical formats attract hero numbers. Smaller. Faster. More efficient. Better. The words are cheap and usually arrive before the test harness, which is exactly the wrong order. For AXIOM, the responsible posture is to treat benchmarks as per-release evidence, not mythology. If the benchmark has not been rerun on current source, current compiler, current flags, and current hardware, it is not a public claim. It is a postcard from a previous afternoon.
What matters more is the verification route. Does encoding and decoding stay within the declared contract? Do operations normalize into a legal shape? Do edge cases around exponent boundaries behave intentionally? Do property tests cover the annoying values that humans forget because humans have hobbies? Does a high-precision oracle exist where comparison is meaningful? Can replay rebuild the same value path?
That last question is the reason this belongs in our stack. Dweve keeps building toward systems where computation leaves evidence: parsers with receipts, ledgers with typed events, retrieval with deterministic paths, data formats that do not haul a wagon of repeated keys, simulation and numeric layers that can replay. AXIOM fits because moving the point should not mean losing the receipt.
The lesson
The lesson of AXIOM is not that fixed-point was wrong. Fixed-point is still one of the cleanest tools we have. The lesson is that one fixed scale is not always enough, and the alternative does not have to be opaque floating behaviour. A value can carry a controlled exponent choice. The point can move while the contract stays visible.
Det är den offentliga historien som är värd att berätta. Dweve AXIOM packar tecken, exponentindex och mantissa. Den väljer från explicita exponentlistor. Den använder heltalsorienterad aritmetik och normaliserar resultaten tillbaka till de deklarerade formerna. Den har konkreta, flexibla, tensor-, block-, stratifierade, APoT- och forskningsvägar i kodbasen. Den hör hemma under Numerus eftersom deterministisk aritmetik inte är en sidouppgift. Det är en del av hur seriösa system ger samma svar två gånger.
Poängen flyttar sig. Ansvaret gör det inte. Det är den användbara biten.