AXIOM et le point qui bouge

La virgule fixe apporte de la rigueur, mais une seule échelle peut gaspiller de la précision. Dweve AXIOM permet à chaque valeur de choisir parmi une liste...

AXIOM et le point qui bouge

Le point a bougé, le contrat n'a pas changé

L'arithmétique à virgule fixe est attrayante parce qu'elle est honnête. Vous choisissez une échelle, vous dites où se trouve le point, et la machine cesse de prétendre que chaque nombre est une minuscule prévision météo. Cela rend la relecture plus sereine, les cibles embarquées plus faciles à raisonner, et les audits moins dépendants d'expressions comme « assez proche ». Charmant. Et incomplet.

Une seule échelle fixe peut être trop grossière. Choisissez une échelle qui gère les très petites valeurs et les valeurs plus grandes manquent de place. Choisissez une échelle qui gère les valeurs plus grandes et les petites valeurs perdent des détails utiles. Vous pouvez répartir la charge de travail entre plusieurs types, mais alors le codebase a un autre genre de désordre. Félicitations, la virgule décimale est devenue un problème d'effectifs.

AXIOM existe pour les cas où le point doit bouger sans transformer la couche numérique en soupe à virgule flottante. Dans le codebase Dweve, c'est une famille adaptative à virgule variable : chaque valeur concrète porte un signe, un index de liste d'exposants et une mantisse dans une représentation compacte de 32 bits. L'exposant n'est pas une humeur matérielle ambiante. Il est sélectionné à partir d'une liste explicite. La mantisse est une charge utile entière. La valeur représentée est le signe multiplié par la mantisse multiplié par deux à la puissance de l'exposant sélectionné négatif. Cette phrase n'est pas mignonne, mais c'est tout l'astuce.

L'important n'est pas que le point bouge. La virgule flottante bouge déjà le point. L'important est qu'AXIOM le déplace à travers une liste déclarée qui peut être revue, testée, spécialisée et maintenue déterministe. Le code ne demande pas à la plateforme d'improviser une personnalité numérique. Il donne à la valeur un contrat compact et fait revenir l'arithmétique à ce contrat après chaque opération.

AXIOM n'est pas une virgule décimale magique. La valeur concrète est un mot compact avec signe, choix d'exposant et mantisse. La discipline utile est que chaque partie a un rôle.

Dans le code source, la forme concrète est Axiom<M, E>. La largeur de la mantisse doit correspondre à la représentation, avec des alias pratiques comme Adp4, Adp8, Adp16, Adp23, AdpNN4 et AdpNN8. Ces noms ne sont pas des décorations. Ils vous disent combien de charge utile et quel profil d'exposant la valeur est censée utiliser. Une valeur avec une liste d'exposants en forme de NN n'est pas la même promesse qu'une valeur avec une liste générale plus large. Les traiter comme identiques parce que les deux semblent numériques, c'est ainsi que les codebases sérieux commencent à accumuler du folklore.

La virgule variable n'est pas une ambiance

L'expression « virgule variable adaptative » peut sembler être un renommage de la virgule flottante pour faire passer un achat en réunion. Ce n'est pas ce qui se passe. AXIOM ne fait pas de l'exposant un effet secondaire invisible. L'exposant est sélectionné à partir d'une liste attachée au type ou à la stratégie. Dans le code source actuel, les listes d'exposants concrètes incluent la liste standard [16, 8, 4, 0], la liste dense [12, 8, 4, 0], les poids de réseaux de neurones [8, 6, 4, 0] et une liste fine [16, 14, 12, 10, 8, 6, 4, 0]. Ce sont les valeurs actuelles du code source, et cette distinction compte parce que le code source a changé au fil du temps ; les affirmations actuelles doivent suivre le code actuel, pas des listes d'exposants obsolètes.

La liste est la décision produit. Une liste standard donne quelques bandes larges. Une liste dense change l'emplacement des bandes. La liste NN est conçue pour des données ressemblant à des poids. La liste fine offre plus de choix proches. Rien de tout cela n'élimine le jugement. Cela déplace le jugement dans un endroit où la revue de code peut le voir.

Voilà la différence entre une représentation adaptative contrôlée et une excuse générale. Un type à virgule fixe dit que chaque valeur ici utilise cette échelle. AXIOM dit que chaque valeur ici choisit parmi cet ensemble déclaré d'échelles. C'est un contrat plus large, pas un contrat manquant. Le point bouge, mais il bouge sur des rails. Très néerlandais, vraiment. Même la virgule décimale a une infrastructure.

La virgule fixe donne une grille uniforme. AXIOM donne un ensemble déclaré de bandes d'exposants. Ce choix supplémentaire n'est utile que parce qu'il reste explicite.

Il vaut la peine d'être précis sur ce qu'AXIOM n'est pas. Ce n'est pas une arithmétique rationnelle exacte. Ce n'est pas une licence pour ignorer l'analyse de plage. Ce n'est pas une revendication de benchmark. Ce n'est pas une garantie que la liste d'exposants choisie correspond à votre charge de travail parce que l'acronyme semblait énergique. Vous devez toujours comprendre les valeurs, la plage dynamique, l'erreur acceptable, la cible de déploiement et les exigences de relecture. AXIOM rend ces choix plus inspectables. Il ne les fait pas disparaître. Si quoi que ce soit, il rend la pensée numérique paresseuse plus difficile à cacher, ce qui est généralement là où les cris commencent.

L'arithmétique doit rentrer à la maison

Un format numérique est facile à dessiner et plus difficile à rendre utile. La partie utile, c'est l'arithmétique. L'addition et la soustraction doivent traiter des valeurs qui peuvent se trouver sur différentes bandes d'exposants. La multiplication et la division doivent effectuer un travail de mantisse entière plus large avant de ramener le résultat à la forme cible. Après l'opération, la valeur doit se normaliser pour revenir à un choix d'exposant disponible. Cette dernière étape compte parce qu'une représentation qui ne peut pas rentrer à la maison n'est qu'un voyage à l'étranger avec un meilleur branding.

L'arithmétique d'AXIOM a donc un rythme. Amener les valeurs compressées. Aligner ou élargir si nécessaire. Effectuer l'opération orientée entiers. Normaliser. Stocker le résultat dans la forme déclarée. Si cela ne correspond pas, cela doit être visible comme un problème de représentation, pas discrètement délégué à l'humeur de la machine. Le contrat est utile parce qu'il a des limites.

C'est la même raison pour laquelle Numerus compte autour de lui. La pile plus large n'essaie pas de collectionner les formats numériques comme des timbres. Elle veut une arithmétique qui puisse survivre à la relecture, au déploiement embarqué, à la simulation, à la compression de modèles, aux tests et aux pistes d'audit. AXIOM est une famille dans cette histoire. Il traite un problème particulier : des valeurs dont l'échelle utile change, mais dont le comportement doit rester déterministe.

L'opération n'est pas terminée quand les mantisses ont été touchées. Le résultat doit revenir à une forme AXIOM déclarée, sinon la représentation a cessé d'être un contrat.

C'est la phrase ennuyeuse qui sauve les équipes plus tard : se normaliser pour revenir à la forme. Cela ressemble à un détail d'implémentation jusqu'à ce qu'une relecture diffère, qu'un seuil bascule ou qu'un modèle compressé se comporte différemment sur une cible plus petite. Ensuite, c'est la phrase que tout le monde aurait souhaité voir dans le document d'architecture.

Pourquoi AXIOM se trouve sous Numerus

L'histoire publique de Numerus est délibérément plus simple que l'arborescence source. La plupart des lecteurs veulent savoir si la couche numérique peut fournir une arithmétique déterministe, des familles à virgule fixe, un comportement décimal, une posture no_std, des profils embarqués orientés entiers, une vérification et la même réponse deux fois. Ils n'ont pas besoin de chaque type interne sur la première page. Ce n'est pas du secret. C'est de la clémence.

Sous cette surface, la couche numérique commune est plus large. Elle porte les types entiers binaires, ternaires, natifs et sous-octets, les alias à virgule fixe, les types liés aux flottants pour les travaux de compatibilité, et l'AXIOM adaptatif. Les traits partagés donnent à ces familles une surface commune. Numerus enveloppe ensuite les éléments destinés à être visibles par les utilisateurs : virgule fixe binaire et décimale, AXIOM, entiers, opérations, surfaces DSL et posture de vérification. Cette séparation est saine. Une fondation peut être vaste sans que la page publique ressemble au menu d'un restaurant qui a perdu confiance.

AXIOM mérite son propre article car il n'est pas qu'une simple entrée de cette liste. La virgule fixe consiste à placer la virgule à un endroit précis. La virgule fixe décimale vise l'exactitude des décimales en base dix. Les formes binaires et ternaires concernent des chemins compacts à faible nombre de bits. AXIOM, lui, fait de la virgule une partie contrôlée de la valeur. Cela change la façon d'envisager la représentation, l'arithmétique, les tests et le déploiement.

Cela change aussi la portée des affirmations publiques. Les performances d'AXIOM appartiennent aux benchmarks actuels sur le code actuel, pas à un folklore hérité. La pile élargie ne doit pas être décrite comme sans aucune opération en virgule flottante, car les surfaces de conversion et d'affichage peuvent franchir cette limite. L'affirmation la plus sûre et la plus précise est que l'arithmétique fixe et adaptative du cœur est orientée entiers et conçue pour un comportement déterministe. Cette phrase est moins tape-à-l'œil. Tant mieux. Les affirmations numériques tape-à-l'œil sont ce qui transforme les tableaux de bord en générateurs d'excuses.

Plusieurs chemins de calcul, une seule famille

La valeur compactée concrète n'est que le début. La source contient plus d'une façon d'utiliser AXIOM, car les charges de travail ne sont pas assez polies pour tenir dans un seul format pour toujours. Il y a le chemin concret compacté pour les listes d'exposants au moment de la compilation. Il y a Flex<S> pour le stockage d'exposants à l'exécution sur des tailles de stockage entières. Il y a des formes tensorielle et par blocs où une structure d'exposants partagée peut être utile. Il y a le traitement stratifié. Il y a l'APoT, où les valeurs peuvent être représentées comme des sommes de puissances de deux signées, de sorte que la multiplication devienne des décalages et des additions. Il y a du code de recherche sur le profilage et les exposants appris autour de tout cela.

Cette diversité n'est pas une raison pour faire des affirmations extravagantes. C'est une raison pour être prudent quant à la charge de travail. Un chemin de relecture scalaire, un chemin de quantification par lots, un chemin de type tensoriel et un chemin de poids APoT subissent des pressions différentes. La disposition mémoire, la réutilisation des exposants, la plage, la normalisation et la forme du matériel comptent toutes. AXIOM fournit un vocabulaire pour ces choix. Il ne dispense personne de les faire.

AXIOM est une famille de chemins de calcul. Les valeurs compactées, le stockage flexible des exposants, les dispositions tensorielles ou par blocs et les chemins de décalage-addition APoT sont des outils différents, pas une seule diapositive marketing.

C'est là que l'ingénierie devient intéressante. L'APoT n'est pas qu'une astuce de compression mignonne. Pour des valeurs adaptées, il transforme la multiplication en un problème de décalage et d'addition. Les chemins tensoriel et par blocs peuvent partager une structure d'exposants lorsqu'une charge de travail a suffisamment de forme. Flex maintient le stockage d'exposants à l'exécution lorsque les listes au niveau des types sont trop rigides. Aucun de ces choix ne devrait être fait parce que le diagramme était joli. C'est la charge de travail qui choisit, sinon le rapport de bug choisira plus tard et sera beaucoup moins aimable.

Comment évaluer un choix AXIOM

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 needsa 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-entrylist. 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 attracthero 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.

Voilà l’histoire publique qui mérite d’être racontée. Dweve AXIOM regroupe signe, index d’exposant et mantisse. Il sélectionne parmi des listes d’exposants explicites. Il utilise une arithmétique orientée entiers et normalise les résultats dans les formes déclarées. Il comporte des chemins concrets, flexibles, tensoriels, par blocs, stratifiés, APoT et de recherche dans la base de code. Il relève de Numerus parce que l’arithmétique déterministe n’est pas une quête secondaire. C’est ainsi que les systèmes sérieux obtiennent deux fois la même réponse.

Le point se déplace. La responsabilité, non. C’est là l’essentiel.