Vender capacidad de cómputo agéntico obliga a responder una pregunta que parece contable y es de metrología: ¿en qué se mide el trabajo que hace un agente? La respuesta ingenua —en tokens— falla por tres motivos independientes, y conviene enunciarlos por separado porque cada uno mata una solución distinta.
El primero es la inconmensurabilidad. Un turno agéntico consume tokens de entrada frescos, tokens de entrada leídos de caché, tokens de salida visible, tokens de razonamiento invisibles, llamadas a herramientas que no producen token alguno, minutos de CPU en un sandbox y efectos externos que no consumen cómputo pero sí gobernanza. Nada de eso se suma. Un techo de gasto necesita un escalar, y no existe ninguno observable.
El segundo es la inestabilidad de la unidad aparente. El token no es una magnitud estable ni siquiera dentro de un mismo proveedor: la propia documentación de Anthropic advierte que sus modelos recientes usan un tokenizador nuevo que «produce aproximadamente un 30 % más de tokens para el mismo texto». Un contrato expresado en tokens cambia de valor cuando el proveedor cambia de tokenizador, sin que el cliente haya hecho nada. Y el precio del token tampoco es una constante: sobre el precio base de entrada se aplican multiplicadores de caché (1,25×, 2×, 0,1× según escritura de cinco minutos, de una hora o lectura), de lote y de residencia de datos, y la documentación dice expresamente que se componen entre sí.
El tercero, y el más incómodo, es que una parte del consumo no es observable por quien paga. Los tokens de razonamiento se facturan como salida y no se devuelven en la respuesta. OpenAI lo dice sin rodeos: los tokens de razonamiento no son visibles a través de la API, ocupan sitio en la ventana de contexto y se facturan como tokens de salida. Anthropic va más lejos y lo convierte en una advertencia explícita: el número de tokens de salida facturados no coincide con el número visible en la respuesta, porque se factura el proceso de pensamiento completo y no el resumen que se devuelve. Cualquier medidor que se limite a contar lo que ve premia sistemáticamente al proveedor más opaco.
De ahí la decisión de fondo de ALLAN: no facturar el recurso crudo, sino construir una escala propia —la Work Unit— sobre la que definir techos, presupuestos y contratos. La escala no es física; es convención versionada. Toda la dificultad del diseño consiste en que una convención pueda ser, aun así, auditable.
La escala construida no es una invención de ALLAN
La industria de infraestructura resolvió el mismo problema antes, y merece la pena leer cómo lo documenta, porque la letra pequeña es donde está el aprendizaje.
Azure SQL define su DTU como «una medida mezclada de CPU, memoria, lecturas y escrituras», y añade que las características físicas asociadas a cada DTU «se calibran usando un benchmark que simula una carga de trabajo real de base de datos». Es medición por procedimiento público, no por física. Lo interesante es el alcance de la garantía que Microsoft se atreve a dar: el modelo DTU garantiza que el rendimiento y el tiempo de respuesta del benchmark permanecen «sustancialmente idénticos» cuando la base se mueve a otro hardware, siempre que el número de DTU no cambie. Y a continuación desactiva la generalización: la documentación del propio benchmark advierte que «todos los benchmarks son representativos e indicativos únicamente» y que «no hay garantía de que una base de datos concreta escale de la misma manera que el benchmark». La escala construida garantiza su ancla, no la carga de usted.
Cosmos DB es todavía más cercano al caso agéntico. Microsoft llama a la Request Unit «una moneda de rendimiento que abstrae los recursos del sistema como procesamiento (CPU), operaciones de entrada/salida por segundo (IOPS) y memoria» y afirma que normaliza el coste de todas las operaciones de base de datos, de modo que «tanto si la operación es una escritura, una lectura puntual o una consulta, las operaciones se miden siempre en RU». Dos propiedades importan aquí. La primera es el determinismo, enunciado como compromiso operativo: «la misma consulta sobre los mismos datos cuesta siempre el mismo número de RU en ejecuciones repetidas». La segunda es que la RU está anclada a una operación de referencia legible: leer un único elemento por su identificador y clave de partición cuesta una RU, y ese elemento debe pesar en torno a 1 KB.
Conviene corregir aquí una creencia extendida y que este ensayo no puede sostener. Se repite que la propiedad clave de la RU es su invariancia respecto a la región o a la partición física. La documentación recuperada no dice eso: dice que el coste es determinista para una operación dada sobre un conjunto de datos dado, y de hecho el aprovisionamiento sí es por región (con N regiones, la capacidad total es R × N). Lo que la RU garantiza es reproducibilidad de la medida, no independencia del despliegue.
El contraejemplo útil es el crédito de CPU de las instancias burstable de EC2, que AWS define dimensionalmente: «1 crédito de CPU = 1 vCPU × 100 % de utilización × 1 minuto». Esa sí es una unidad física, y por eso mismo no sirve para medir trabajo heterogéneo: sólo mide una cosa.
Y para la separación entre unidad y dinero existe un precedente reciente y directamente pertinente: la Claude Consumption Unit. Anthropic tarifica en dólares, aplica descuentos y después convierte a una unidad abstracta —«cien (100) CCU representan 1,00 USD de tarifas»— cuyo precio es fijo; los descuentos se aplican metiendo menos CCU, nunca cambiando el precio de la CCU. Es la operación inversa a la de ALLAN, y precisamente por eso ilumina el contraste: la CCU es dinero disfrazado de unidad, mientras que el WU está construido para que la conversión a dinero no exista en ningún sentido.
Lo que ALLAN descartó, y con qué motivo
El corpus de diseño registra los descartes con su motivo textual, que es lo que permite reabrirlos sin repetir la discusión.
El modelo previo de rating por créditos-token fue abandonado en la versión 4
del diseño porque conservaba equivalencias WU↔USD —una restricción de precio
contra COGS y una calibración de K contra $/WU— que contradecían el objetivo:
«el dinero jamás define, deriva ni calibra la unidad de trabajo»
(docs/economia/work-units-design.md:8). El modelo v6 lo eleva a prohibición
estructural, incluyendo la de usar $/WU «como definición u objetivo de
calibración» y la de publicar cualquier equivalencia WC↔dinero
(docs/economia/economic-model-redesign.md:60-63).
El factor de clase de ejecución κ se aplica sólo a la entrada: «el
razonamiento ya se contabiliza por su volumen en la salida a peso 4; multiplicar
también la salida por κ sería doble incremento»
(work-units-design.md:174-176). El razonamiento no entra en crudo sino
convertido a T_reasoning_rated, «para que un proveedor que oculta el
razonamiento no parezca artificialmente más eficiente que otro que lo declara»
(:150-152). El tiempo de reloj queda fuera del medidor porque «pertenece al SLA
de los tamaños, no al medidor» (:49), con la única excepción del minuto de CPU
de sandbox. Cada operación tiene exactamente una base más modificadores
acumulables, lo que «evita que CRM-vía-MCP sume HTTP+MCP+acción externa por
separado» (:215). El almacenamiento se declara «stock, no flujo» y queda fuera
de la unidad (:270). Y el tope de salida por clase no puede ser la defensa
principal, porque un tope que sirve el exceso gratis «invitaría a pedir salidas
enormes pagando siempre el techo» (:275): de ahí que la reserva por llamada
exista, y que el tope quede documentado en el código como un simple respaldo
(Economics/economics/domain/rating.py:145-148).
El ancla es una identidad, no un parámetro
La definición operativa es breve. Una llamada cognitiva se tarifica como
WU_cog = [ κ_in·(w_in·T_in_nc + w_cache·T_in_c) + w_out·(T_visible + T_razonamiento_tarifado) ] / N
con w_in = 1,0, w_cache = 0,1, w_out = 4,0 y N = 4.000
(rating.py:122-127). El valor de N no se elige: se despeja. La primera
llamada de referencia del dominio —2.000 tokens de entrada no cacheada y 500 de
salida visible en clase fast— es la definición del ancla
(rating.py:533-543), y derive_n_anchor resuelve la única N que hace que esa
llamada valga exactamente 1 WU (Economics/economics/domain/lint.py:180-201). La
regla ANCHOR-001 vuelve a tarificar el ancla con la función autoritativa y
bloquea la escritura si el resultado no es 1.000 milliWU, con el remedio
literal: «n_anchor debe ser {derived} con estos pesos (es una identidad, no una
elección)» (lint.py:443-467). Ejecutando el rateador puro contra los vectores
compartidos, el ancla tarifa hoy en 1.000 milliWU exactos y los catorce vectores
cognitivos reproducen sin discrepancia.
Es la misma construcción que la lectura puntual de 1 KB que vale una RU: un acto de referencia elegido para que la unidad sea legible por una persona («esta misión costó 141 turnos de chat de trabajo»), no un descubrimiento empírico.
Redenominar sin romper lo firmado
Si los pesos se mueven, la unidad compra otra cosa. El diseño lo llama por su
nombre —redenominación— y lo instrumenta. _max_drift_permille vuelve a
tarificar un conjunto de sondas con la configuración activa y con la propuesta, y
mide el mayor movimiento relativo (lint.py:235-248). Por encima de cinco por
mil, la regla ANCHOR-002 declara: «El cambio mueve el valor de la unidad: es una
redenominación», con la consecuencia enunciada —«la capacidad que concede cada
plan pasaría a comprar una cantidad de trabajo distinta sin que el plan haya
cambiado»— y el remedio: reexpresar la capacidad mensual de todos los planes en
el mismo cambio (lint.py:469-500).
Lo que protege lo ya firmado no es el validador, sino la inmutabilidad. Las filas
de wu_config son inmutables y un cambio es una versión nueva, no una edición
(Economics/economics/services/rating_config.py:1-8); create_version se niega
a sobrescribir con un mensaje que explica por qué —«una versión publicada es una
promesa sobre lo que se cobró a una misión pasada»—
(rating_admin.py:193-212); cada misión congela la versión con la que abrió y se
lleva los pesos dentro del contrato (missions.py:216,241-245;
Platform Server/internal/economics/client.go:131-159); y config_for_version
devuelve None antes que sustituir por la activa, porque «recalcular un cargo
pasado con los pesos de hoy produce un número que nunca ocurrió»
(rating_config.py:77-88). La denominación K está congelada por la regla
UNIT-001, que es bloqueante (lint.py:394-412), y el diseño prohíbe además el
ajuste encubierto: «"K no cambia" pero los pesos hacen que las mismas tareas
gasten el doble» (work-units-design.md:420).
Compatibilidad de incentivos frente al razonamiento oculto
El medidor no puede premiar la opacidad. reasoning_measurement distingue cuatro
calidades —native, budgeted, estimated, unavailable— y
rated_reasoning_tokens resuelve, para cada una, qué cifra entra en la fórmula
(rating.py:50-62, :225-242). Si el proveedor declara, se usa lo declarado. Si
se autorizó un presupuesto de razonamiento y no vuelve nada, se usa el
presupuesto. Si no hay nada, se aplica el valor por defecto conservador de la
clase: 2.000 tokens en las clases de razonamiento, cero en fast, y cero en
embeddings porque ahí «es un hecho, no una suposición» (rating.py:163-175).
Las fuentes recuperadas confirman que el problema es real y añaden dos matices
que el diseño no modela. El primero: un presupuesto de razonamiento no es un
tope. Anthropic dice que «el presupuesto es un objetivo, no un límite estricto» y
que el modelo puede detenerse mucho antes de agotarlo; usar el presupuesto como
cifra tarifada, que es lo que hace el modo budgeted, sobrecarga en ese caso. El
segundo, más profundo: los bloques de razonamiento de turnos anteriores que
permanecen en contexto «se facturan como tokens de entrada» en los modelos que
los conservan. En la fórmula de ALLAN el razonamiento pesa 4,0 sin κ cuando sale,
y pesa κ·1,0 cuando vuelve como entrada en el turno siguiente. No es un error de
cálculo, pero sí una asimetría que el diseño no discute.
Aritmética entera y una sola división
Dos implementaciones tarifan: la autoritativa en Python
(Economics/economics/domain/rating.py) y la del camino caliente en Go
(Platform Server/internal/economics/rating.go), porque el motor necesita
tarifar antes de emitir la llamada y no puede esperar a un viaje de red. Ambas
están ancladas a los mismos vectores de conformidad
(testdata/wu_rating_vectors.json), que la migración semilla replica en la base
para que un despliegue nuevo tarife igual desde la primera petición
(Economics/migrations/versions/0002_seed_rating_and_plans.py:7-8).
Todo es aritmética entera en milliWU, y hay exactamente una división. Los dos
términos se escalan a un factor común de 10⁶ antes de dividir, porque «el
redondeo intermedio es lo que hace que dos implementaciones se separen»
(rating.py:245-272; rating.go:219-241). El redondeo es half-up explícito y
propio, y el motivo está documentado en los dos ficheros: el round de Python
redondea al par y el math.Round de Go redondea alejándose de cero, y ambos
discrepan en las mitades exactas. Las dos documentaciones oficiales lo confirman:
Python dice que «si dos múltiplos están igual de cerca, el redondeo se hace hacia
la opción par (de modo que, por ejemplo, tanto round(0.5) como round(-0.5)
son 0)», y Go dice que «Round devuelve el entero más cercano, redondeando las
mitades alejándose de cero». Verificado en esta sesión: round(0.5) devuelve 0
en Python, mientras que el vector rounding_half_up —dos tokens de entrada en
clase fast, valor exacto 0,5 milliWU— exige 1 y el rateador devuelve 1.
La conversión a la unidad comercial se hace una sola vez, al liquidar:
1 WC = K × 1.000 milliWU, exacta para K = 10 (rating.py:475-485). Redondear
por evento dejaría miles de restos deambulando por un total que nadie podría
conciliar (work-units-design.md:399-409).
El dinero entra por un solo sitio
La separación es la razón de ser de la arquitectura de tres capas: la capa de
trabajo produce WU sin dinero; la capa comercial vende WC, y el dinero aparece
sólo en el precio del plan y del pack; la capa de costes vigila la viabilidad por
plan y no toca jamás la definición de la unidad. El rateador es puro por
construcción —sin E/S, sin reloj, sin base de datos— y su docstring enuncia el
invariante como segundo de tres: «Nada aquí sabe de dólares, precios de proveedor
ni planes» (rating.py:11-23). La consola lo repite como invariante de producto:
no muestra ni deja calcular un $/WC
(docs/economia/economics-console-design.md:530-535).
Invariantes, enunciados de forma falsable
Un lector puede refutar cualquiera de estos con el repositorio delante.
Misma telemetría y misma versión de rating producen los mismos milliWU en Python
y en Go, y una discrepancia rompe las dos suites porque ambas leen el mismo
fichero de vectores. La llamada ancla tarifa exactamente 1.000 milliWU o la
escritura se rechaza como BLOCKING. k_denomination distinto de 10 se rechaza
como BLOCKING. w_cache mayor o igual que w_in se rechaza como BLOCKING
(lint.py:375-392). Ninguna función del módulo de rating consulta un precio, una
divisa ni un identificador comercial de modelo. Toda operación tiene exactamente
una base. En la fórmula, κ multiplica el término de entrada y sólo ese. Una
versión de rating publicada no se edita: se crea otra. Una misión conserva la
versión con la que abrió aunque se active otra a mitad de ejecución.
Lo que está roto, sin terminar o sin evidencia
La reserva por llamada no está cableada. ClampCall existe, está probada y no
la invoca ningún punto de producción: la búsqueda en todo el repositorio devuelve
únicamente su definición (internal/economics/budget.go:275-280) y dos tests. El
mecanismo que el diseño presenta como defensa principal contra la salida enorme
—y que justifica que el tope por clase sea sólo un respaldo— hoy no se ejecuta.
Dos de las cuatro calidades de medición del razonamiento son código muerto en
el motor. reasoningMeasurementFor sólo devuelve native o unavailable
(internal/models/openai.go:599-613), ReasoningBudgetTokens no se asigna en
ningún sitio de producción, y normalizedUsageFrom no rellena ni
ConfiguredEffort ni EstimatorVersion
(cmd/allan-server/economics.go:201-228). El estimador versionado, que el diseño
presenta como la pieza que impide que una actualización de adaptador cambie en
silencio lo que costó una misión pasada, no tiene hoy ninguna llamada que lo
active.
El guardián de redenominación es ciego al peso de la caché. Las sondas de
extended_reference_usages se generan replicando la llamada ancla, que tiene
input_cached_tokens = 0; las veinte sondas comparten ese cero. Comprobado
ejecutando el validador: subir w_cache_milli de 100 a 900 arroja una deriva
medida de 0 por mil y lint_rating_config no devuelve ningún problema, de
modo que la versión se escribe y se activa limpia. Sobre una conversación larga
con caché (1.000 tokens frescos, 20.000 cacheados, 600 de salida) ese mismo
cambio pasa de 1.350 a 5.350 milliWU: casi cuatro veces más por el mismo trabajo.
CACHE-001 no lo detiene porque sólo exige que w_cache sea estrictamente menor
que w_in.
La redenominación se avisa pero no se ejecuta. ANCHOR-002 tiene severidad
error, no blocking, y raise_if_blocking sólo detiene lo bloqueante
(lint.py:145-156). La decisión es explícita y está razonada —bloquear todo
movimiento «congelaría la calibración del shadow-rating que el propio modelo
prescribe» (Economics/economics/config.py:103-105)—, pero la segunda mitad de
la regla, reexpresar la capacidad de todos los planes en el mismo cambio, no
tiene ningún código detrás: la búsqueda de «redenominat» en todo el árbol sólo
encuentra el validador, sus umbrales y comentarios.
La auditoría de re-tarifado compara contra la versión equivocada.
audit_rating_sample recupera eventos recientes y los vuelve a tarifar con
rating_config.active(deps) (Economics/economics/worker.py:116), aunque tiene
en la mano event.rating_config_version —lo registra en el log de la
discrepancia, línea 141— y aunque existe config_for_version escrito
precisamente para esto. En cuanto haya una segunda versión activa, todo evento
tarifado con la anterior se registrará como rating_divergence sin que los dos
rateadores discrepen en nada.
Los vectores compartidos no cubren la entrada malformada, y ahí las dos
implementaciones divergen. Ante una base de operación desconocida, Python lanza
ValueError (rating.py:368-372) y Go devuelve cero
(rating.go:311-315); ante un modificador desconocido, Python lanza y Go lo
ignora; ante una versión de estimador desconocida, Python lanza y Go cae a v1.
Las tres decisiones de Go están comentadas y son defendibles en el camino
caliente, pero significan que una herramienta mal clasificada se cobra a cero en
el motor mientras el servicio la habría rechazado. Los vectores no lo detectan
porque sólo contienen entradas bien formadas.
Un turno no retenido se tarifa con los pesos compilados. Cuando Economics no
responde, o no está midiendo, authorizeTurn devuelve un estado sin presupuesto
(cmd/allan-server/economics.go:389-413) y RatingConfig() cae a
DefaultRatingConfig() (internal/economics/budget.go:81-86). El evento llega
al ledger sellado como wu-config-v1 aunque la versión activa del despliegue sea
otra. Es honesto —dice con qué se midió— y a la vez es una vía por la que la
tabla publicada deja de gobernar el camino más transitado del producto.
El ancla no está validada contra tráfico real. El diseño reserva la
calibración definitiva a la fase B del shadow-rating
(work-units-design.md:493), y esa fase no ha producido números contractuales
visibles en el código. Hoy el ancla se comprueba contra sí misma: ANCHOR-001
verifica que la llamada de referencia vale 1 WU con los pesos declarados, que es
una identidad algebraica, no una medida. La advertencia de Microsoft sobre su
propio benchmark —representativo e indicativo únicamente— se aplica aquí con más
fuerza todavía, porque en ALLAN el benchmark ni siquiera se ha corrido.
El corpus se contradice a sí mismo en el punto más sensible. El propio
documento que prohíbe publicar equivalencias WC↔dinero publica una:
«crédito=$0.01, GM 75-80%» (work-units-design.md:530). No es una inconsistencia
menor: es exactamente la clase de frase que, citada fuera de contexto, convierte
la unidad en dinero disfrazado.
Queda, por último, un defecto adyacente que afecta a lo que la unidad mide:
open_mission calcula el presupuesto con la variante ya degradada por el plan
pero pide los límites de recursos con la variante solicitada
(Economics/economics/services/missions.py:138 frente a :237). Un tenant
degradado de M a S recibe presupuesto de S con envolvente de M.
Referencias
-
Microsoft. 2026. DTU-Based Purchasing Model — Azure SQL Database. https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tiers-dtu?view=azuresql. «A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes.» Y sobre el alcance de la garantía: «The DTU model guarantees that the throughput and response time of the DTU benchmark workload will remain substantially identical as the database moves to a different hardware type, as long as its service objective (the number of DTUs) stays the same.»
-
Microsoft. 2025. DTU Benchmark — Azure SQL Database. https://learn.microsoft.com/en-us/azure/azure-sql/database/dtu-benchmark?view=azuresql. «Physical characteristics (CPU, memory, IO) associated with each DTU measure are calibrated using a benchmark that simulates real-world database workload.» Y la cautela que este ensayo usa contra el propio anclaje de ALLAN: «It's important to understand that all benchmarks are representative and indicative only. […] There is no guarantee that any particular database will scale in the same way as the benchmark under increasing load.»
-
Microsoft. 2025. Request Units as a throughput and performance currency — Azure Cosmos DB. https://learn.microsoft.com/en-us/azure/cosmos-db/request-units. «A request unit is a performance currency that abstracts the system resources such as processing (CPU), input/output operations per second (IOPS), and memory that are required to perform the database operations supported by Azure Cosmos DB.» Sobre la unidad única: «Whether the database operation is a write, point read, or query, operations are always measured in RUs.» Sobre el determinismo: «The same query on the same data always costs the same number of RUs on repeated executions.» Sobre el ancla: «reading a single item by its ID and partition key uses one request unit. The item should be about 1 KB in size.» Nota de rigor: esta página no afirma invariancia por región o partición, al contrario de lo que suele repetirse; la afirmación se ha retirado del texto.
-
Amazon Web Services. Key concepts for burstable performance instances. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html. Definición dimensional, usada aquí como contraejemplo de escala construida: «CPU credit A unit of vCPU-time. Examples: 1 CPU credit = 1 vCPU * 100% utilization * 1 minute.»
-
Anthropic. 2026. Pricing. https://platform.claude.com/docs/en/about-claude/pricing. Sobre la inestabilidad del token: «This tokenizer produces approximately 30% more tokens for the same text.» Sobre los multiplicadores de caché y su composición: «A cache hit costs 10% of the standard input price, which means caching pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write).» Sobre la separación entre unidad y dinero: «A CCU is a unit of measure used solely for Marketplace Platform invoicing. One hundred (100) CCU represents $1.00 USD of fees owed for the Services, calculated at the applicable prices […] after application of any discounts.»
-
Anthropic. 2026. Steering thinking. https://platform.claude.com/docs/en/build-with-claude/thinking-steering-and-cost. «The billed output token count does not match the visible token count in the response. You are billed for the full thinking process, not the thinking content visible in the response.» Y sobre el razonamiento que vuelve como entrada: «Thinking blocks from prior assistant turns that remain in context […] (billed as input tokens)».
-
Anthropic. 2026. Extended thinking. https://platform.claude.com/docs/en/build-with-claude/extended-thinking. La frase que matiza el modo
budgetedde ALLAN: «The budget is a target rather than a strict cap. Actual token usage varies with the task, and Claude may stop reasoning well before the budget is exhausted;max_tokensremains the hard ceiling on total output.» -
OpenAI. Reasoning. https://developers.openai.com/api/docs/guides/reasoning. «While reasoning tokens are not visible via the API, they still occupy space in the model's context window and are billed as output tokens.»
-
Python Software Foundation. Built-in Functions —
round. https://docs.python.org/3/library/functions.html#round. «For the built-in types supportinground(), values are rounded to the closest multiple of 10 to the power minus ndigits; if two multiples are equally close, rounding is done toward the even choice (so, for example, bothround(0.5)andround(-0.5)are0, andround(1.5)is2).» -
The Go Authors. Package math —
Round. https://pkg.go.dev/math#Round. «Round returns the nearest integer, rounding half away from zero.»
Referencias del catálogo previo que no se han podido recuperar y que, en consecuencia, no se citan ni se usan en el cuerpo: el Reglamento (CE) n.º 1103/97 del Consejo sobre continuidad de contratos y reglas de conversión al euro, que habría servido como precedente jurídico de redenominación —EUR-Lex devuelve la página sin texto articulado a través de las tres URL probadas, y la réplica de legislation.gov.uk no permitió extraer el texto literal—; y el artículo de Goldberg sobre aritmética de coma flotante, recuperado pero sin ninguna frase que sostenga la afirmación que se le atribuía (la acumulación de error por redondeos intermedios), por lo que el argumento de «una sola división» se apoya aquí en la documentación de los dos lenguajes y en la comprobación directa sobre los vectores.