Az AXIOM és a mozgó pont
A tizedesvessző helye változott, a szerződés nem
A fixpontos aritmetika azért vonzó, mert őszinte. Kiválasztasz egy skálát, megmondod, hol van a tizedesvessző, és a gép abbahagyja, hogy úgy tegyen, mintha minden szám egy apró időjárás-előrejelzés lenne. Ez nyugodtabbá teszi a visszajátszást, könnyebben átgondolhatóvá a beágyazott célokat, és az auditok kevésbé függenek az olyan kifejezésektől, mint a nagyjából pontos. Csodálatos. És hiányos is.
Egyetlen fix skála túl durva lehet. Ha olyan skálát választasz, amely a nagyon kis értékeket kezeli, a nagyobb értékeknek elfogy a helyük. Ha olyan skálát választasz, amely a nagyobb értékeket kezeli, a kis értékek elveszítik a hasznos részletességet. A munkát szétoszthatod több típusra, de akkor a kódbázisban egy másfajta rendetlenség lesz. Gratulálok, a tizedesvessző mostantól személyzeti probléma.
Az AXIOM azokra az esetekre létezik, amikor a tizedesvesszőnek mozognia kell anélkül, hogy a numerikus réteg visszaváltozna lebegőpontos káosszá. A Dweve kódbázisban ez egy adaptív változó-pontos család: minden konkrét érték hordoz egy előjelet, egy kitevőlista-indexet és egy mantisszát egy tömör 32 bites reprezentációban. A kitevő nem a hardver hangulata. Egy explicit listából van kiválasztva. A mantissza egy egész számból álló adatmező. A reprezentált érték az előjel szorozva a mantisszával, szorozva kettő a negatív kiválasztott kitevőn. Ez a mondat nem cuki, de ez az egész trükk.
A fontos rész nem az, hogy a tizedesvessző mozog. A lebegőpontos már úgyis mozgatja. A fontos rész az, hogy az AXIOM egy deklarált listán keresztül mozgatja, amely áttekinthető, tesztelhető, specializálható és determinisztikus marad. A kód nem kéri a platformot, hogy improvizáljon egy numerikus személyiséget. Értéket ad az értéknek egy tömör szerződés formájában, és az aritmetika minden művelet után visszatér ehhez a szerződéshez.
A forrásban a konkrét alak Axiom<M, E>. A mantissza szélességének illeszkednie kell a reprezentációhoz, gyakorlati aliasokkal, mint Adp4, Adp8, Adp16, Adp23, AdpNN4 és AdpNN8. Ezek a nevek nem díszek. Megmondják, mennyi adatot és milyen kitevőprofilt kell használnia az értéknek. Egy NN alakú kitevőlistával rendelkező érték nem ugyanazt az ígéretet jelenti, mint egy tágabb általános listával rendelkező érték. Ha ugyanolyanként kezeled őket, mert mindkettő numerikusnak tűnik, így kezdenek el a komoly kódbázisok folklórt gyűjteni.
A változó pont nem hangulat
Az adaptív változó pont kifejezés úgy hangozhat, mintha valaki átnevezte volna a lebegőpontosat, hogy átmenjen a beszerzésen. Nem ez történik. Az AXIOM nem teszi a kitevőt láthatatlan mellékhatássá. A kitevő egy listából van kiválasztva, amely a típushoz vagy stratégiához van kötve. A jelenlegi forrásban a konkrét kitevőlisták közé tartozik a standard [16, 8, 4, 0], a sűrű [12, 8, 4, 0], a neurális hálózati súlyok [8, 6, 4, 0] és egy finom lista [16, 14, 12, 10, 8, 6, 4, 0]. Ezek a jelenlegi forrásértékek, és ez a megkülönböztetés azért fontos, mert a forrás idővel változott; a jelenlegi állításoknak a jelenlegi kódot kell követniük, nem elavult kitevőlistákat.
A lista a termékdöntés. Egy standard lista néhány széles sávot ad. Egy sűrű lista megváltoztatja a sávok helyét. Az NN lista a súlyszerű adatokhoz van alakítva. A finom lista több közeli választási lehetőséget kínál. Egyik sem veszi el az ítélőképességet. Áthelyezi az ítélőképességet egy olyan helyre, ahol a kódáttekintés látja.
Ez a különbség egy ellenőrzött adaptív reprezentáció és egy általános kifogás között. Egy fixpontos típus azt mondja, hogy minden itteni érték ezt a skálát használja. Az AXIOM azt mondja, hogy minden itteni érték a deklarált skálakészletből választ. Ez tágabb szerződés, nem hiányzó szerződés. A pont mozog, de sínen mozog. Nagyon holland. Még a tizedespontnak is van infrastruktúrája.
Érdemes pontosan megfogalmazni, hogy mi nem az AXIOM. Nem egzakt racionális aritmetika. Nem felhatalmazás a tartományelemzés figyelmen kívül hagyására. Nem benchmark-állítás. Nem garancia arra, hogy a választott exponenslista illik a munkaterheléshez, csak mert a mozaikszó energikusnak tűnt. Továbbra is értened kell az értékeket, a dinamikatartományt, az elfogadható hibát, a telepítési célt és a visszajátszási követelményeket. Az AXIOM ezeket a döntéseket átláthatóbbá teszi. Nem tünteti el őket. Ha valami, akkor megnehezíti a lusta numerikus gondolkodás elrejtését, és általában itt kezdődik a visítozás.
Az aritmetikának haza kell érnie
Egy számformátumot könnyű lerajzolni, de nehezebb hasznossá tenni. A hasznos rész az aritmetika. Az összeadásnak és a kivonásnak olyan értékekkel kell megbirkóznia, amelyek különböző exponenssávokon lehetnek. A szorzásnak és az osztásnak szélesebb egész mantisszamunkát kell végeznie, mielőtt visszaadja az eredményt a célalakba. A művelet után az értéket vissza kell normalizálni egy elérhető exponensválasztásba. Ez az utolsó lépés azért fontos, mert egy reprezentáció, amely nem tud hazatérni, csak egy jobb márkájú külföldi nyaralás.
Az AXIOM-aritmetikának ezért van ritmusa. Pakolt értékeket hoz be. Igazít vagy szélesít, ahogy kell. Elvégzi az egész-orientált műveletet. Normalizál. Visszatárolja az eredményt a deklarált alakba. Ha nem fér bele, annak reprezentációs problémaként kell látszania, nem pedig csendben a gép hangulatára bízva. A szerződés azért hasznos, mert vannak élei.
Ez az oka annak is, hogy a Numerus számít körülötte. A tágabb verem nem bélyegekként gyűjti a számformátumokat. Olyan aritmetikát akar, amely túléli a visszajátszást, a beágyazott telepítést, a szimulációt, a modelltömörítést, a teszteket és az auditnyomokat. Az AXIOM egy család ebben a történetben. Egy konkrét problémát kezel: olyan értékeket, amelyek hasznos skálája változik, de amelyek viselkedésének determinisztikusnak kell maradnia.
Ez az unalmas mondat, amely később megmenti a csapatokat: normalizálj vissza alakba. Implementációs részletnek hangzik, amíg egy visszajátszás el nem tér, egy küszöb át nem billen, vagy egy tömörített modell másként nem viselkedik egy kisebb célon. Akkor azzá a mondattá válik, amelyet mindenki szeretne, hogy benne legyen az architektúradokumentumban.
Miért ül az AXIOM a Numerus alatt
A nyilvános Numerus-történet szándékosan egyszerűbb, mint a forrásfa. A legtöbb olvasó azt akarja tudni, hogy a numerikus réteg tud-e determinisztikus aritmetikát, fixpontos családokat, decimális viselkedést, no_std hozzáállást, egész-orientált beágyazott profilokat, verifikációt és kétszer ugyanazt a választ adni. Nem kell minden belső típus az első oldalon. Ez nem titkolózás. Ez irgalom.
Alatta a közös numerikus réteg szélesebb. Bináris, hármas, natív és albyte méretű egész típusokat, fixpontos aliasokat, kompatibilitási munkához használt lebegőpontos típusokat és adaptív AXIOM-ot hordoz. A közös trait-ek közös felületet adnak ezeknek a családoknak. A Numerus ezután körbeöleli azokat a darabokat, amelyeknek termékfelületre kell kerülniük: bináris és decimális fixpontot, AXIOM-ot, egész számokat, műveleteket, DSL-felületeket és verifikációs hozzáállást. Ez a szétválasztás egészséges. Egy alapréteg lehet széles anélkül, hogy a nyilvános oldal úgy nézne ki, mint egy étlap egy olyan étteremből, amely elvesztette az önbizalmát.
Az AXIOM megérdemel egy saját cikket, mert nem csak egy újabb tétel ebben a listában. A fixpont arról szól, hogy a tizedesvessző egy helyen legyen. A decimális fixpont a pontos tízes alapú helyiértékekről szól. A bináris és hármas formák a kompakt, kis bitszélességű utakról szólnak. Az AXIOM arról szól, hogy a tizedesvessző az érték ellenőrzött része legyen. Ez megváltoztatja, ahogyan a reprezentációról, az aritmetikáról, a tesztekről és az üzembe helyezésről gondolkodsz.
Az is megváltozik, hogyan kell keretezni a nyilvános állításokat. Az AXIOM teljesítménye a jelenlegi benchmarkokhoz tartozik a jelenlegi kódon, nem örökölt folklórhoz. A tágabb verem nem írható le úgy, hogy nulla lebegőpontos műveletet végez, mert az átalakítási és megjelenítési felületek átléphetik ezt a határt. A biztonságosabb és pontosabb állítás az, hogy a mag fix és adaptív aritmetikája egész számokra orientált, és determinisztikus viselkedésre tervezett. Ez a mondat kevésbé hivalkodó. Jó. A hivalkodó numerikus állításoktól lesznek az irányítópultok bocsánatkérő gépekké.
Több számítási út, egy család
A konkrét csomagolt érték csak a kezdet. A forrás több mint egy módot kínál az AXIOM használatára, mert a munkaterhelések nem elég udvariasak ahhoz, hogy örökre egy elrendezésbe illeszkedjenek. Létezik a csomagolt konkrét út a fordítási időben ismert kitevőlistákhoz. Létezik a Flex<S> a futásidejű kitevőtároláshoz egész tárolóméretek felett. Vannak tenzor- és blokkformák, ahol a megosztott kitevőszerkezet hasznos lehet. Létezik rétegzett feldolgozás. Létezik az APoT, ahol az értékek előjeles kettő hatványok összegeként ábrázolhatók, így a szorzás eltolásokká és összeadásokká válhat. Vannak körülötte profilozási és tanult kitevőkkel kapcsolatos kutatási kódok.
Ez a széles skála nem ok arra, hogy vad állításokat tegyünk. Ez ok arra, hogy óvatosak legyünk a munkaterheléssel kapcsolatban. Egy skaláris visszajátszási útnak, egy kötegelt kvantálási útnak, egy tenzorszerű útnak és egy APoT súlyútnak különböző nyomásai vannak. A memóriaelrendezés, a kitevő-újrafelhasználás, a tartomány, a normalizálás és a hardver alakja is számít. Az AXIOM szókincset ad ezekhez a választásokhoz. Nem mentesít senkit azok meghozatala alól.
Itt válik érdekessé a mérnöki munka. Az APoT nem csupán egy aranyos tömörítési trükk. Megfelelő értékeknél a szorzást eltolás-összeadás problémává alakítja. A tenzor- és blokkutak megoszthatják a kitevőszerkezetet, ha egy munkaterhelésnek elég alakja van. A Flex futásidejű kitevőtárolást tesz elérhetővé, amikor a típus szintű listák túl merevek. Egyiket sem azért kell kiválasztani, mert a diagram szépen nézett ki. A munkaterhelés választ, vagy a hibajelentés választ később, és sokkal kevésbé lesz bájos.
Hogyan értékelj egy AXIOM-választást
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.
Ez az a nyilvános történet, amelyet érdemes elmesélni. A Dweve AXIOM csomagok előjelet, kitevőindexet és mantisszát tartalmaznak. Explicit kitevőlistákból válogat. Egész számokra épülő aritmetikát használ, és az eredményeket visszanormalizálja a deklarált alakzatokba. Konkrét, rugalmas, tenzor, blokk, rétegzett, APoT és kutatási útvonalak vannak a kódbázisban. A Numerus alá tartozik, mert a determinisztikus aritmetika nem mellékszál. Ez része annak, ahogyan a komoly rendszerek kétszer is ugyanazt a választ adják.
A lényeg elmozdul. A felelősség nem. Ez a hasznos rész.