O AXIOM e o ponto que se move
O ponto mudou, o contrato não
A aritmética de ponto fixo é atraente porque é honesta. Escolhe-se uma escala, diz-se onde o ponto vive, e a máquina deixa de fingir que cada número é uma previsão meteorológica minúscula. Isso torna a repetição mais calma, os alvos embutidos mais fáceis de raciocinar e as auditorias menos dependentes de expressões como mais ou menos. Adorável. Também incompleto.
Uma escala fixa pode ser demasiado bruta. Escolhe-se uma escala que lida com valores muito pequenos e os valores maiores ficam sem espaço. Escolhe-se uma escala que lida com valores maiores e os valores pequenos perdem detalhe útil. Pode-se dividir a carga de trabalho em vários tipos, mas agora o código tem um tipo diferente de confusão. Parabéns, o ponto decimal é agora um problema de pessoal.
AXIOM existe para os casos em que o ponto precisa de se mover sem transformar a camada numérica novamente em sopa de vírgula flutuante. No código Dweve, é uma família de ponto variável adaptativo: cada valor concreto carrega um sinal, um índice de lista de expoentes e uma mantissa numa representação compacta de 32 bits. O expoente não é um humor ambiental do hardware. É selecionado a partir de uma lista explícita. A mantissa é um payload inteiro. O valor representado é sinal vezes mantissa vezes dois elevado ao expoente selecionado negativo. Essa frase não é bonita, mas é todo o truque.
A parte importante não é que o ponto se move. A vírgula flutuante já move o ponto. A parte importante é que AXIOM o move através de uma lista declarada que pode ser revista, testada, especializada e mantida determinística. O código não pede à plataforma para improvisar uma personalidade numérica. Dá ao valor um contrato compacto e faz a aritmética voltar a esse contrato após cada operação.
No código-fonte, a forma concreta é Axiom<M, E>. A largura da mantissa deve caber na representação, com aliases práticos como Adp4, Adp8, Adp16, Adp23, AdpNN4 e AdpNN8. Esses nomes não são decorações. Dizem-lhe quanto payload e que perfil de expoente o valor deve usar. Um valor com uma lista de expoentes em forma de NN não é a mesma promessa que um valor com uma lista geral mais ampla. Tratá-los como iguais porque ambos parecem numéricos é como os códigos sérios começam a colecionar folclore.
Ponto variável não é vibes
A expressão ponto variável adaptativo pode soar como se alguém tivesse renomeado a vírgula flutuante para passar uma reunião de aquisições. Não é isso que está a acontecer. AXIOM não torna o expoente um efeito colateral invisível. O expoente é selecionado a partir de uma lista anexada ao tipo ou à estratégia. No código-fonte atual, as listas concretas de expoentes incluem a padrão [16, 8, 4, 0], a densa [12, 8, 4, 0], a de pesos de redes neuronais [8, 6, 4, 0] e uma lista fina [16, 14, 12, 10, 8, 6, 4, 0]. Esses são os valores atuais do código-fonte, e essa distinção importa porque o código mudou ao longo do tempo; as afirmações atuais devem seguir o código atual, não listas de expoentes desatualizadas.
A lista é a decisão de produto. Uma lista padrão dá algumas bandas largas. Uma lista densa muda onde as bandas ficam. A lista NN é moldada para dados semelhantes a pesos. A lista fina oferece mais escolhas próximas. Nada disso remove o julgamento. Move o julgamento para um lugar onde a revisão de código o pode ver.
Esta é a diferença entre uma representação adaptativa controlada e uma desculpa genérica. Um tipo de ponto fixo diz que todos os valores aqui usam esta escala. AXIOM diz que todos os valores aqui escolhem a partir deste conjunto declarado de escalas. Isso é um contrato mais amplo, não um contrato em falta. O ponto move-se, mas move-se sobre carris. Muito holandês, na verdade. Até o ponto decimal tem infraestrutura.
Vale a pena ser preciso sobre o que AXIOM não é. Não é aritmética racional exata. Não é uma licença para ignorar a análise de intervalo. Não é uma alegação de benchmark. Não é uma garantia de que a lista de expoentes escolhida se adequa à sua carga de trabalho porque o acrónimo parecia enérgico. Ainda precisa de compreender os valores, o intervalo dinâmico, o erro aceitável, o alvo de implantação e os requisitos de reprodução. AXIOM torna essas escolhas mais inspecionáveis. Não as faz desaparecer. Se alguma coisa, torna mais difícil esconder o pensamento numérico preguiçoso, que é normalmente onde começam os gritos.
A aritmética tem de voltar para casa
Um formato numérico é fácil de desenhar e mais difícil de tornar útil. A parte útil é a aritmética. A adição e a subtração têm de lidar com valores que podem estar em bandas de expoente diferentes. A multiplicação e a divisão têm de fazer um trabalho mais amplo de mantissa inteira antes de devolver o resultado à forma pretendida. Após a operação, o valor tem de normalizar de volta para uma escolha de expoente disponível. Esse último passo é importante porque uma representação que não consegue voltar para casa é apenas umas férias no estrangeiro com melhor branding.
A aritmética AXIOM tem, portanto, um ritmo. Trazer valores compactados. Alinhar ou alargar conforme necessário. Executar a operação orientada a inteiros. Normalizar. Guardar o resultado de volta na forma declarada. Se não couber, isso deve ser visível como um problema de representação, não delegado silenciosamente ao humor da máquina. O contrato é útil porque tem limites.
Esta é a mesma razão pela qual Numerus importa à sua volta. A pilha mais ampla não tenta colecionar formatos numéricos como selos. Quer aritmética que possa sobreviver a reprodução, implantação embutida, simulação, compressão de modelos, testes e trilhos de auditoria. AXIOM é uma família dentro dessa história. Trata de um problema particular: valores cuja escala útil muda, mas cujo comportamento ainda tem de ser determinístico.
Essa é a frase aborrecida que poupa equipas mais tarde: normalizar de volta para a forma. Parece um detalhe de implementação até uma reprodução diferir, um limiar mudar ou um modelo comprimido comportar-se de forma diferente num alvo mais pequeno. Então torna-se a frase que todos gostariam que estivesse no documento de arquitetura.
Porque é que AXIOM fica sob Numerus
A história pública de Numerus é deliberadamente mais simples do que a árvore de código-fonte. A maioria dos leitores quer saber se a camada numérica pode fornecer aritmética determinística, famílias de ponto fixo, comportamento decimal, postura no_std, perfis embutidos orientados a inteiros, verificação e a mesma resposta duas vezes. Não precisam de todos os tipos internos na primeira página. Isso não é secretismo. Isso é misericórdia.
Por baixo, a camada numérica comum é mais ampla. Transporta tipos inteiros binários, ternários, nativos e sub-byte, aliases de ponto fixo, tipos relacionados com floats para trabalho de compatibilidade e AXIOM adaptativo. As traits partilhadas dão a essas famílias uma superfície comum. A Numerus envolve depois as peças que devem estar viradas para o produto: ponto fixo binário e decimal, AXIOM, inteiros, operações, superfícies DSL e postura de verificação. Esta separação é saudável. Uma fundação pode ser ampla sem fazer a página pública parecer um menu de um restaurante que perdeu a confiança.
A AXIOM merece um artigo próprio porque não é apenas mais uma entrada nessa lista. O ponto fixo consiste em colocar o ponto num único lugar. O ponto fixo decimal consiste em casas decimais exatas na base dez. As formas binárias e ternárias dizem respeito a caminhos compactos de poucos bits. A AXIOM consiste em tornar o ponto uma parte controlada do valor. Isso muda a forma como se pensa sobre representação, aritmética, testes e implementação.
Também muda a forma como as afirmações públicas devem ser delimitadas. O desempenho da AXIOM pertence aos benchmarks atuais em código atual, não a folclore herdado. A stack mais ampla não deve ser descrita como zero operações de vírgula flutuante, porque as superfícies de conversão e apresentação podem cruzar essa fronteira. A afirmação mais segura e mais precisa é que a aritmética fixa e adaptativa do núcleo é orientada a inteiros e concebida para comportamento determinístico. Essa frase é menos chamativa. Ainda bem. Afirmações numéricas chamativas são a forma como os dashboards se tornam geradores de pedidos de desculpas.
Vários caminhos de computação, uma família
O valor compactado concreto é apenas o começo. O código-fonte contém mais do que uma forma de usar a AXIOM, porque as cargas de trabalho não são suficientemente educadas para caberem num único layout para sempre. Existe o caminho concreto compactado para listas de expoentes em tempo de compilação. Existe Flex<S> para armazenamento de expoentes em tempo de execução sobre tamanhos de armazenamento inteiros. Existem formas de tensor e de bloco onde uma estrutura de expoente partilhada pode ser útil. Existe processamento estratificado. Existe APoT, onde os valores podem ser representados como somas de potências de dois com sinal, para que a multiplicação se possa tornar em deslocamentos e adições. Existe código de investigação de perfis e de expoentes aprendidos à volta disso.
Essa dispersão não é motivo para fazer afirmações exageradas. É motivo para ter cuidado com a carga de trabalho. Um caminho de reprodução escalar, um caminho de quantização em lote, um caminho semelhante a tensor e um caminho de pesos APoT têm pressões diferentes. O layout de memória, a reutilização de expoentes, o intervalo, a normalização e a forma do hardware são todos importantes. A AXIOM dá um vocabulário para essas escolhas. Não isenta ninguém de as fazer.
É aqui que a engenharia fica interessante. A APoT não é apenas um truque de compressão engraçado. Para valores adequados, transforma a multiplicação num problema de deslocamento e adição. Os caminhos de tensor e de bloco podem partilhar a estrutura de expoente quando uma carga de trabalho tem forma suficiente. A Flex mantém o armazenamento de expoentes em tempo de execução disponível quando as listas ao nível do tipo são demasiado rígidas. Nenhuma destas opções deve ser escolhida porque o diagrama tinha bom aspeto. A carga de trabalho escolhe, ou o relatório de bug escolherá mais tarde e será muito menos simpático a esse respeito.
Como rever uma escolha de 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 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.
Essa é a história pública que vale a pena contar. O Dweve AXIOM empacota sinal, índice de expoente e mantissa. Ele seleciona a partir de listas explícitas de expoentes. Usa aritmética orientada a inteiros e normaliza os resultados de volta para as formas declaradas. Tem caminhos concretos, flexíveis, de tensor, de bloco, estratificados, APoT e de pesquisa no código. Pertence ao Numerus porque a aritmética determinística não é uma missão secundária. É parte de como sistemas sérios produzem a mesma resposta duas vezes.
O ponto muda. A responsabilidade não. É essa a parte útil.