Axiom og det punkt, der bevæger sig
Punktet flyttede sig, kontrakten gjorde ikke
Fikspunkt-aritmetik er tiltrækkende, fordi den er ærlig. Du vælger en skala, du siger, hvor punktet ligger, og maskinen holder op med at lade, som om hvert tal er en lille vejrudsigt. Det gør replay roligere, indlejrede mål nemmere at ræsonnere om, og revisioner mindre afhængige af vendinger som tæt nok. Dejligt. Også ufuldstændigt.
Én fast skala kan være for grov. Vælger du en skala, der håndterer meget små værdier, løber de større værdier tør for plads. Vælger du en skala, der håndterer større værdier, mister de små værdier nyttige detaljer. Du kan dele arbejdsbyrden op i flere typer, men så har kodebasen en anden slags rod. Tillykke, decimalpunktet er nu et bemandingsproblem.
AXIOM findes til de tilfælde, hvor punktet skal flytte sig uden at forvandle det numeriske lag tilbage til flydende-komma-suppe. I Dweve-kodebasen er det en adaptiv variabel-punkt-familie: hver konkret værdi bærer et fortegn, et indeks i en eksponentliste og en mantisse i en pakket 32-bit-repræsentation. Eksponenten er ikke en omgivende hardware-stemning. Den vælges fra en eksplicit liste. Mantissen er en heltals-payload. Den repræsenterede værdi er fortegn gange mantisse gange to opløftet i minus den valgte eksponent. Den sætning er ikke sød, men den er hele tricket.
Det vigtige er ikke, at punktet flytter sig. Flydende komma flytter allerede punktet. Det vigtige er, at AXIOM flytter det gennem en erklæret liste, der kan gennemgås, testes, specialiseres og holdes deterministisk. Koden beder ikke platformen om at improvisere en numerisk personlighed. Den giver værdien en kompakt kontrakt og får aritmetikken til at vende tilbage til den kontrakt efter hver operation.
I kildekoden er den konkrete form Axiom<M, E>. Mantissebredden skal passe til repræsentationen, med praktiske aliasser som Adp4, Adp8, Adp16, Adp23, AdpNN4 og AdpNN8. De navne er ikke dekoration. De fortæller dig, hvor meget payload og hvilken eksponentprofil værdien skal bruge. En værdi med en NN-formet eksponentliste er ikke det samme løfte som en værdi med en bredere generel liste. At behandle dem som ens, fordi begge ser numeriske ud, er sådan seriøse kodebaser begynder at samle på folkeviden.
Variabelt punkt er ikke stemning
Udtrykket adaptivt variabelt punkt kan lyde, som om nogen har omdøbt flydende komma for at få indkøb igennem et møde. Det er ikke det, der sker. AXIOM gør ikke eksponenten til en usynlig bivirkning. Eksponenten vælges fra en liste, der er knyttet til typen eller strategien. I den aktuelle kildekode omfatter de konkrete eksponentlister standard [16, 8, 4, 0], tæt [12, 8, 4, 0], neuralt-netværks-vægte [8, 6, 4, 0] og en fin liste [16, 14, 12, 10, 8, 6, 4, 0]. Det er de aktuelle kildekodeværdier, og den skelnen betyder noget, fordi kildekoden har ændret sig over tid; aktuelle påstande bør følge aktuel kode, ikke forældede eksponentlister.
Listen er produktbeslutningen. En standardliste giver et par brede bånd. En tæt liste ændrer, hvor båndene ligger. NN-listen er formet til vægtlignende data. Den fine liste tilbyder flere nærliggende valg. Intet af det fjerner dømmekraft. Det flytter dømmekraften til et sted, hvor kodegennemgang kan se den.
Dette er forskellen mellem en kontrolleret adaptiv repræsentation og en generel undskyldning. En fixed-point-type siger, at hver værdi her bruger denne skala. AXIOM siger, at hver værdi her vælger fra dette erklærede sæt af skalaer. Det er en bredere kontrakt, ikke en manglende. Punktet bevæger sig, men det bevæger sig på skinner. Meget hollandsk, faktisk. Selv decimaltegnet har infrastruktur.
Det er værd at være præcis om, hvad AXIOM ikke er. Det er ikke eksakt rationel aritmetik. Det er ikke en licens til at ignorere rækkeviddeanalyse. Det er ikke et benchmark-krav. Det er ikke en garanti for, at den valgte eksponentliste passer til din arbejdsbyrde, fordi akronymet så energisk ud. Du skal stadig forstå værdierne, det dynamiske område, den acceptable fejl, implementeringsmålet og afspilningskravene. AXIOM gør disse valg mere inspicerbare. Det får dem ikke til at forsvinde. Hvis noget, gør det doven numerisk tænkning sværere at skjule, hvilket normalt er der, hvor skriget begynder.
Aritmetik skal komme hjem
Et talformat er let at tegne og sværere at gøre nyttigt. Den nyttige del er aritmetikken. Addition og subtraktion skal håndtere værdier, der kan ligge på forskellige eksponentbånd. Multiplikation og division skal udføre bredere heltals-mantissearbejde, før resultatet returneres til målformen. Efter operationen skal værdien normaliseres tilbage til et tilgængeligt eksponentvalg. Det sidste trin betyder noget, fordi en repræsentation, der ikke kan komme hjem, bare er en ferie i udlandet med bedre branding.
AXIOM-aritmetik har derfor en rytme. Bring pakkede værdier ind. Juster eller udvid efter behov. Udfør den heltalsorienterede operation. Normaliser. Gem resultatet tilbage i den erklærede form. Hvis det ikke passer, skal det være synligt som et repræsentationsproblem, ikke stille og roligt delegeret til maskinens humør. Kontrakten er nyttig, fordi den har kanter.
Dette er samme grund til, at Numerus betyder noget omkring det. Den bredere stak forsøger ikke at samle talformater som frimærker. Den vil have aritmetik, der kan overleve afspilning, indlejret implementering, simulering, modelkomprimering, test og revisionsspor. AXIOM er én familie i den historie. Den håndterer et bestemt problem: værdier, hvis nyttige skala ændrer sig, men hvis adfærd stadig skal være deterministisk.
Det er den kedelige sætning, der senere redder teams: normaliser tilbage til formen. Det lyder som implementeringsdetalje, indtil en afspilning afviger, en tærskel vender, eller en komprimeret model opfører sig anderledes på et mindre mål. Så bliver det sætningen, alle ville ønske havde stået i arkitekturdokumentet.
Hvorfor AXIOM ligger under Numerus
Den offentlige Numerus-historie er bevidst enklere end kilde-træet. De fleste læsere vil vide, om det numeriske lag kan give deterministisk aritmetik, fixed-point-familier, decimaladfærd, no_std-holdning, heltalsorienterede indlejrede profiler, verifikation og det samme svar to gange. De behøver ikke hver intern type på første side. Det er ikke hemmelighedskræmmeri. Det er barmhjertighed.
Underneath, det fælles numeriske lag er bredere. Det bærer binære, ternære, native og sub-byte heltalstyper, fixed-point-aliaser, float-relaterede typer til kompatibilitetsarbejde og adaptiv AXIOM. De fælles traits giver disse familier en fælles overflade. Numerus pakker derefter de dele, der skal vende mod produktet: binær og decimal fixed-point, AXIOM, heltal, operationer, DSL-overflader og verifikationsprofil. Denne adskillelse er sund. Et fundament kan være bredt uden at få den offentlige side til at ligne en menu fra en restaurant, der har mistet selvtilliden.
AXIOM fortjener sin egen artikel, fordi det ikke bare er endnu en post på den liste. Fixed-point handler om at placere punktet ét sted. Decimal fixed-point handler om eksakte base-ti-placeringer. Binære og ternære former handler om kompakte lav-bit-stier. AXIOM handler om at gøre punktet til en kontrolleret del af værdien. Det ændrer, hvordan du tænker om repræsentation, aritmetik, tests og implementering.
Det ændrer også, hvordan offentlige påstande bør afgrænses. AXIOM-ydelse tilhører aktuelle benchmarks på aktuel kode, ikke nedarvet folklore. Den bredere stak bør ikke beskrives som nul flydende komma-operationer, fordi konverterings- og visningsflader kan krydse den grænse. Den sikrere og mere præcise påstand er, at den centrale faste og adaptive aritmetik er heltalsorienteret og designet til deterministisk adfærd. Den sætning er mindre prangende. Godt. Prangende numeriske påstande er sådan, dashboards bliver til undskyldningsgeneratorer.
Flere beregningsstier, én familie
Den konkrete pakkede værdi er kun begyndelsen. Kilden indeholder mere end én måde at bruge AXIOM på, fordi arbejdsbelastninger ikke er høflige nok til at passe ind i ét layout for evigt. Der er den pakkede konkrete sti til kompileringstids-eksponentlister. Der er Flex<S> til runtime-eksponentlagring over heltalslagringsstørrelser. Der er tensor- og blokformer, hvor delt eksponentstruktur kan være nyttig. Der er stratificeret behandling. Der er APoT, hvor værdier kan repræsenteres som summer af fortegnede toerpotenser, så multiplikation kan blive til skift og additioner. Der er profilerings- og lært eksponentforskningskode omkring det.
Den spredning er ikke en grund til at komme med vilde påstande. Det er en grund til at være omhyggelig med arbejdsbelastningen. En skalar replay-sti, en batch-kvantiseringssti, en tensor-lignende sti og en APoT-vægtsti har forskellige pres. Hukommelseslayout, eksponentgenbrug, rækkevidde, normalisering og hardwareform har alle betydning. AXIOM giver et ordforråd til de valg. Det fritager ikke nogen fra at træffe dem.
Det er her, ingeniørarbejdet bliver interessant. APoT er ikke blot et sødt komprimeringstrick. For passende værdier ændrer det multiplikation til et skift-og-add-problem. Tensor- og blokstier kan dele eksponentstruktur, når en arbejdsbelastning har tilstrækkelig form. Flex holder runtime-eksponentlagring tilgængelig, når type-niveau-lister er for stive. Ingen af disse bør vælges, fordi diagrammet så pænt ud. Arbejdsbelastningen vælger, eller også vælger fejlrapporten senere og er langt mindre charmerende om det.
Sådan vurderer du et AXIOM-valg
Det første review-spørgsmål er kedeligt og derfor nyttigt: hvorfor ikke en enklere taltype? Hvis værdien er penge eller et reguleret decimalbeløb, kan Decimal være det rigtige svar. Hvis intervallet er lille og velafgrænset, kan en Q-format fastpunkts-type være mere rolig. Hvis tallet kun findes for at interoperere med et filformat eller en ekstern API, kan en float-relateret type være den ærlige edge-adapter. AXIOM tjener sin plads, når arbejdsbyrden har skiftende størrelsesorden, stadig har brug for en deterministisk kontrakt, og drager fordel af et eksplicit eksponentsæt.
Det andet spørgsmål er, om eksponentlisten beskriver dataene eller blot smigrer ingeniøren. En liste med fire brede bånd er en anden afvejning end en finkornet liste med otte indgange. NN-formet liste er ikke en dekorativ etiket. Den siger, at værdierne forventes at opføre sig som vægtdata. Hvis fordelingen ikke matcher listen, vil repræsentationen stadig køre. Software er ofte villig til at gøre det forkerte med imponerende hastighed. Det gør det ikke til et design.
Det tredje spørgsmål er, hvor normaliseringspresset opstår. Addition på tværs af fjerne eksponentbånd kan kassere detaljer. Multiplikation kan skabe et resultat, der har brug for et andet bånd. Gentagne operationer kan akkumulere pres præcis de steder, demoen ikke besøgte. Reviewet bør bede om grænsetests omkring nul, fortegnsskift, eksponentovergange, store mantisser og gentagne operationer. Hvis de tilfælde føles irriterende, er det godt. De er sandsynligvis de tilfælde, der betyder noget.
Det sidste spørgsmål er, hvordan repræsentationen efterlader beviser. Hvilken typealias valgte vi? Hvilken eksponentliste? Hvilken mantissebredde? Hvilken konverteringssti? Hvilken orakel- eller property-test bakker påstanden op? Hvis svaret er spredt ud over kommentarer og optimisme, har systemet allerede mistet noget af fordelen. AXIOM er mest nyttigt, når det numeriske valg bliver en del af arkitekturjournalen, ikke et smart lokalt trick gemt tre moduler nede.
Verifikation slår heltetal
Numeriske formater tiltrækker heltetal. Mindre. Hurtigere. Mere effektivt. Bedre. Ordene er billige og ankommer normalt før testopsætningen, hvilket er præcis den forkerte rækkefølge. For AXIOM er den ansvarlige holdning at behandle benchmarks som beviser pr. release, ikke mytologi. Hvis benchmarket ikke er kørt igen på aktuel kildekode, aktuel compiler, aktuelle flag og aktuel hardware, er det ikke et offentligt krav. Det er et postkort fra en tidligere eftermiddag.
Det, der betyder mere, er verifikationsvejen. Holder kodning og afkodning sig inden for den erklærede kontrakt? Normaliserer operationer til en lovlig form? Opfører kanttilfælde omkring eksponentgrænser sig bevidst? Dækker property-tests de irriterende værdier, som mennesker glemmer, fordi mennesker har hobbyer? Findes der et højpræcisions-orakel, hvor sammenligning giver mening? Kan replay genopbygge den samme værdisti?
Det sidste spørgsmål er grunden til, at dette hører hjemme i vores stack. Dweve bliver ved med at bygge mod systemer, hvor beregning efterlader beviser: parsere med kvitteringer, hovedbøger med typede hændelser, hentning med deterministiske stier, dataformater, der ikke slæber en vogn med gentagne nøgler, simulerings- og numeriske lag, der kan afspilles. AXIOM passer ind, fordi flytning af punktet ikke skal betyde, at man mister kvitteringen.
Lærdommen
Lærdommen fra AXIOM er ikke, at fastpunkt var forkert. Fastpunkt er stadig et af de reneste værktøjer, vi har. Lærdommen er, at én fast skala ikke altid er nok, og alternativet behøver ikke at være uigennemsigtig float-adfærd. En værdi kan bære et kontrolleret eksponentvalg. Punktet kan flytte sig, mens kontrakten forbliver synlig.
Det er den offentlige historie, der er værd at fortælle. Dweve AXIOM pakker fortegn, eksponentindeks og mantisse. Den vælger fra eksplicitte eksponentlister. Den bruger heltalsorienteret aritmetik og normaliserer resultater tilbage til deklareret former. Den har konkrete, fleksible, tensor-, blok-, stratificerede, APoT- og forskningsstier i kodebasen. Den hører under Numerus, fordi deterministisk aritmetik ikke er en sideopgave. Det er en del af, hvordan seriøse systemer får det samme svar to gange.
Pointen flytter sig. Ansvaret gør ikke. Det er den nyttige del.