Numerus och samma svar två gånger
The bug that only exists on the other machine
The most irritating numeric bug is the one that refuses to appear where you are looking. The test fails on CI, not locally. The simulation drifts after a dependency update. The embedded target produces a slightly different result from the server. The model pipeline looks fine until replay asks for the same calculation twice and receives two answers that are close enough to start an argument.
Close is sometimes fine. Close is not always a contract. If a calculation is part of a replay path, a safety check, a simulation, a pricing decision, a digital twin, an audit trail, or a model compression step, then close can turn into a product risk. The difference may be tiny. Tiny differences are still differences. Software has made entire careers out of being offended by tiny differences.
This is the reason Numerus exists in the Dweve stack. The Numerus page frames it as an open-source numeric foundation for deterministic arithmetic: binary and decimal fixed-point, Dweve AXIOM adaptive variable-point math, integer-oriented operation, Rust, no_std-capable surfaces, verification against high-precision references where meaningful, and deterministic profiles intended to make replay calmer across supported targets. The shared common numeric layer underneath is wider still: binary, ternary, integer, fixed, float, and adaptive AXIOM families under one Element-style contract. The exact implementation details matter to engineers. The product lesson is simpler: arithmetic is not background noise. It is infrastructure.
That sounds obvious until you follow where numbers travel. A simulation feeds a digital twin. The twin feeds a dashboard. The dashboard informs a human decision. The decision is recorded. A month later somebody asks why. If the numeric layer cannot reproduce the calculation,the rest of the evidence chain becomes wobbly. It may still be defensible, but now the team has to explain an avoidable source of drift. That is a bad hobby.
Floating point is not morally wrong
This is not a sermon about floating point being evil.Floating point is one of the reasons modern computing works. It is fast, compact, well supported, and exactly right for many workloads. The problem starts when teams pretend its behaviour is a universal governance contract.
Floating point lives in a worldof rounding modes, hardware differences, compiler choices, instruction selection, fused operations, vectorization, denormals, library behaviour, and target-specific details. Most of the time this is manageable. Sometimes it is even invisible. Then you need bit-exact replay, or cross-target parity, or deterministic simulation, or a build that should behave the same after being moved from server to edge. Suddenly the details stop being academic. They become a meeting.
Numerus takes a different path for workloads where repeatability matters more than pretending every operation is a tiny weather system. Integer-only arithmetic makes the representation explicit. Fixed-point formats define where the decimal lives. Decimal families handle values where exact places matter. Dweve AXIOM gives a way to adapt exponent shape per value without handing control back to an opaque floating environment. The point is not one numeric form forever. The point is choosing a form with a contract.
Det spelar roll, eftersom produktsystem inte bara beräknar. De minns. De spelar upp. De jämför. De förklarar. Om samma beräkning ger olika resultat på olika plattformar blir skillnaden en del av produkten, oavsett om någon planerat det eller inte.
Ett numeriskt bibliotek är egentligen flera löften
En numerisk grund är inte en enda sak. Den är en uppsättning löften med olika målgrupper. Inbyggda systemutvecklaren bryr sig om att begränsade plattformar kan köra de relevanta heltalsorienterade profilerna utan att dra med sig en bekväm serverkörningsmiljö. Simuleringsingenjören bryr sig om att uppspelning kan återskapa ett tillstånd. Revisorn bryr sig om att svarsvägen kan förklaras. Produktägaren bryr sig om att systemet inte beter sig som en nervös miniräknare när det flyttas mellan olika miljöer.
Den publika Numerus-sidan lyfter fram de familjer som de flesta frågar om först: Q-format fixed-point, Decimal och AXIOM. Kodbasen är bredare. common/numeric innehåller binära XNOR- och POPCNT-former, ternära värden, inbyggda och sub-byte-heltal, fixed-point-alias, små flyttalsformat och adaptiv AXIOM. Numerus-fasaden lägger sedan till de produktinriktade decimal- och aritmetiska ytorna runt den grunden. Den uppdelningen är viktig eftersom den undviker den falska elegansen i att tvinga in varje tal i en enda kostym.
Det här är mycket europeisk ingenjörskonst i bästa bemärkelse. Mindre drama, mer kontrakt. Beräkningen ska tala om vad den är. Intervallet ska vara känt. Decimalbeteendet ska vara tydligt. Plattformens begränsningar ska respekteras. Resultatet ska vara reproducerbart. Ingen behöver en keynote för det. De behöver att det fungerar.
AXIOM förtjänar en egen artikel, eftersom det inte bara är ännu ett alias i listan. Det är Dweves adaptiva variabelpunktsfamilj: tecken, exponentindex och mantissa packade i en kompakt representation, med exponentlistor valda för generella, täta, finkorniga eller neuralt nätverksformade data. Det här inlägget placerar bara in det i Numerus-kartan. Den djupare historien handlar om hur adaptiv exponentvalsgivning ger föränderliga magnituder mer utrymme utan att göra aritmetiken icke-deterministisk igen.
Det förhindrar också överdrivna påståenden. Numerus gör inte alla numeriska problem enkla. Det tar inte bort behovet av att välja skalor, intervall, avrundningsbeteende, exponentlistor, mantissbredder eller verifieringsdomäner. Fixed-point- och variabelpunktsaritmetik kan båda missbrukas med stor entusiasm. Värdet är att missbruket blir mer synligt. Ett tydligt numeriskt kontrakt ger dig något att granska. Ett dolt flyttalsantagande ger dig ett litet spöke i produktionen.
Verifiering är inte en märkning
Varje numeriskt bibliotek lär sig så småningom att ord som korrekt och precis är billiga tills de kopplas till en testmiljö. Korrekt var? Precis jämfört med vad? Över vilken indatadomän? Med vilket avrundningsbeteende? I vilken version? Under vilka tester?
Numerus-materialet sätter verifiering i förgrunden: heltalsbaserad CORDIC för transcendentala funktioner, jämförelse mot en högprecisions-MPFR-orakel, egenskapsbaserade tester och releasekontroller. Det exakta påståendet är bara meningsfullt när det kopplas till den maskineriet. En märkning som säger korrekt är dekoration. En testmiljö som jämför, krymper och misslyckas är ingenjörskonst.
Denna skillnad är viktig eftersom numeriska buggar ofta gömmer sig vid kanterna. Mitten av domänen beter sig. Demon beter sig. De vanliga värdena beter sig. Sedan anländer gränsvärdet med en urklippstavla. Negativa indata, värden nära noll, överflödesgränser, skalövergångar, avrundningsjämvikter, exponentlistans gränser och upprepade operationer är där numeriska bibliotek antingen förtjänar förtroende eller börjar skriva skönlitteratur.
Egenskapstestning är användbar eftersom människor är dåliga på att föreställa sig alla sätt ett tal kan vara besvärligt på. En högprecisionsorakel är användbar eftersom implementationen behöver en referens som inte är sig själv. Utgivningskontroller är användbara eftersom ett verifierat påstående från förra månaden inte är en garanti för denna månad. Programvara förblir inte korrekt av artighet.
Determinism hör hemma i arkitekturen, inte i en fotnot
Det är frestande att behandla deterministisk aritmetik som en lågnivådetalj i biblioteket. Det är där många team förlorar den. När produkten väl behöver uppspelning är de numeriska antagandena redan utspridda över tjänster, anteckningsböcker, inbäddade mål, modellverktyg och integrationstester. Då blir determinism en eftermontering. Eftermonteringar är där budgetar går för att utveckla karaktär.
Rätt ögonblick att besluta om numerisk hållning är tidigt. Behöver denna arbetsbelastning bitstabil uppspelning? Korsar den maskiner? Korsar den arkitekturer? Stöder den ett reglerat beslut? Matar den en simulering? Blir den träningsdata, inferensindata, modellkomprimeringsutdata eller ett digitalt tvillingtillstånd? Om ja, är aritmetiken arkitektonisk.
Numerus passar bredvid FMI och Twin av exakt den anledningen. FMI bryr sig om deterministiska simuleringskärnor och modellutbyte. Twin bryr sig om att spela upp operationellt eller fysiskt tillstånd över tid. Ledger registrerar operationella händelser. Trace bär på uppspelningsbar beräkningsbevisning. Dessa lager blir bara lugnare när det numeriska lagret under inte driver som en shoppingvagn med ett dåligt hjul.
I AI-system blir detta ännu mer konkret. Kvantisering, poängsättning, rangordning, simulering, begränsningar, kalibrering, komprimering och uppspelning använder alla tal. Om dessa tal beter sig olika mellan miljöer kanske modellen inte är den skyldiga parten. Den är helt enkelt den mest synliga misstänkta. Bekvämt, men inte alltid korrekt.
Små maskiner är inte andra klassens medborgare
Mycket AI- och simuleringsarkitektur antar tyst en bekväm maskin. Det kommer att finnas en server. Det kommer att finnas en GPU. Det kommer att finnas tillräckligt med minne. Det kommer att finnas en molntjänst. Det kommer att finnas en räkning som får någon att uppfinna frasen strategisk investering.
Verkliga system är mindre prydliga. Vissa beräkningar behöver köras på inbäddade mål. Vissa lever vid kanten. Vissa sitter i enheter utan flyttalsenhet. Vissa behöver no_std-kompatibilitet. Vissa behöver fortsätta fungera när nätverket inte är inbjudet. Om den numeriska grunden bara beter sig i det bekväma fallet är den inte en grund. Den är möbler.
Heltalsorienterad aritmetik hjälper här eftersom den minskar beroendet av målspecifikt flyttalsbeteende där arbetsbelastningen kan använda dessa profiler. no_std-kompatibla ytor hjälper eftersom inte alla miljöer har standardbibliotekets bekvämligheter som en serverprocess. Poängen är inte nostalgi för mindre maskiner. Det handlar om kontroll över vilket numeriskt kontrakt som färdas till begränsade mål.
Detta är inte nostalgi för mindre maskiner. Det handlar om kontroll. Om beräkningen är en del av produkten, borde produkten inte kräva den mest bekväma miljön bara för att vara pålitlig.
Det tråkiga exemplet är det viktiga
Tänk dig en doseringsberäkning, en tariffberäkning, ett simuleringssteg, ett uppspelat sensorvärde eller en tröskel för modellkomprimering. Inget av detta låter glamoröst. Bra. Glamour är vanligtvis där svammlet börjar. Det är i de tråkiga exemplen som numerisk determinism visar sitt värde.
Om resultatet används en gång och glöms bort, kanske små avvikelser inte spelar någon roll. Om resultatet spelas in och spelas upp, spelar det roll. Om det jämförs mellan miljöer, spelar det roll. Om det ligger till grund för ett senare beslut, spelar det roll. Om en kund, revisor eller ingenjör kan fråga varför detta värde dök upp, spelar det definitivt roll. Vid den tidpunkten är beräkningen inte längre en intern implementeringsdetalj. Den är en del av den berättelse produkten förmedlar.
Det är därför Numerus inte bara är ett matematikbibliotek i abstrakt mening. Det är en komponent i en evidensarkitektur. Det ger andra system ett lugnare numeriskt lager att stå på. Reed kan tolka källkod med kvitton. Ledger kan registrera händelser. BitWeave kan göra hämtning deterministisk. HEDL kan göra strukturerad data mindre slösaktig. Numerus gör aritmetiken mindre hal. Varje del tar bort en plats där systemet annars skulle rycka på axlarna.
Lärdomen
Lärdomen från Numerus är att siffror är produktbeteende. Inte bara implementeringsdetalj. Inte bara matematik. Beteende. Om samma indata kan ge ett annat svar när det flyttas till en annan stödd miljö, tillhör den skillnaden nu produkten.
Deterministisk aritmetik krävs inte alltid. När den krävs, bör den designas in istället för att tiggas fram senare. Välj explicita numeriska familjer. Verifiera mot en orakel. Testa hörnen. Respektera distributionsbegränsningar. Ha uppspelning i åtanke innan den första incidentrapporten gör alla plötsligt filosofiska.
Numerus är användbart eftersom det förvandlar aritmetik till ett kontrakt som resten av stacken kan lita på. Binär, ternär, heltal, fast, flyttal, Decimal och AXIOM är inte slagord. De är sätt att forma siffror så att samma svar kan dyka upp två gånger, medvetet. AXIOM får sin egen djupare berättelse eftersom det är den del där själva poängen börjar röra sig medan kontraktet förblir deterministiskt. Det är inte flashigt. Det är bättre än flashigt. Det är den sortens tråkighet som gör att seriösa system kan sova gott om natten.