Por qué 0.1 + 0.2 no es 0.3 en tu código

El problema silencioso que vive en casi todo el código que escribiste

Abre una consola de Python, JavaScript o C# y escribe 0.1 + 0.2. El resultado no es 0.3. Es 0.30000000000000004. No es un bug de tu código. Es el comportamiento estándar del punto flotante IEEE 754, el sistema que prácticamente todos los lenguajes de programación modernos usan por defecto para manejar números decimales.

Durante décadas, los desarrolladores aprendieron a convivir con esto: redondear resultados, usar librerías especiales para aritmética de precisión, o simplemente ignorar el problema y rezar para que los errores de centavos no se acumularan en un sistema financiero. En julio de 2026, un artículo publicado en Dev.to sobre el lenguaje Raku volvió a poner este tema sobre la mesa — y la solución que propone es tan elegante que vale la pena analizar qué implica para quienes diseñamos y construimos software.

En este artículo exploramos qué hace diferente a Raku en su manejo matemático, qué podemos aprender de su diseño, y por qué esto importa más allá de ser una curiosidad académica.

¿Por qué 0.1 + 0.2 no es 0.3 en la mayoría de lenguajes?

El punto flotante IEEE 754 representa los números decimales en binario. El problema es que fracciones simples como 1/10 no tienen representación binaria exacta — es como intentar escribir 1/3 en decimal: siempre necesitas infinitos dígitos. La computadora guarda una aproximación, y esa aproximación introduce error.

El trade-off es deliberado: el punto flotante es extremadamente rápido en hardware moderno y ocupa poco espacio. Para física, simulaciones, gráficos 3D o machine learning, es la herramienta correcta. El problema aparece cuando ese mismo sistema se usa para dinero, contabilidad o cálculos donde la exactitud importa más que la velocidad.

Raku toma una decisión de diseño diferente: los literales decimales son, por defecto, números racionales — fracciones exactas. El 0.1 se almacena internamente como 1/10. El 0.2 como 1/5. La suma 1/10 + 1/5 = 3/10, que al mostrarse es exactamente 0.3. Sin aproximaciones, sin error acumulado.

Las otras características matemáticas que hacen a Raku notable

La aritmética racional es la más llamativa, pero Raku tiene un conjunto de decisiones de diseño que juntas cuentan una historia coherente sobre cómo debería verse un lenguaje matemáticamente honesto.

Los enteros no tienen límite de tamaño. No hay un entero de 64 bits que explote silenciosamente cuando superas el máximo. Puedes calcular el factorial de 100 (158 dígitos) o elevar 2 a la 100 directamente, sin importar librerías externas ni tipos especiales. El lenguaje simplemente crece el número tanto como necesite.

Los superíndices Unicode son operadores reales. Puedes escribir 2⁵ en lugar de 2**5, o verificar el triple pitagórico 5-12-13 con 5² + 12² == 13² — exactamente como lo escribirías en papel. El lenguaje acepta también el símbolo × para multiplicar, ÷ para dividir, ≤ y ≠ para comparaciones, y constantes como π, τ e ∞ como valores de primera clase.

El método .is-prime está disponible directamente sobre cualquier entero, incluyendo números de decenas de dígitos como el primo de Mersenne 2¹²⁷ − 1. Y cuando sí necesitas punto flotante clásico — para simulaciones, por ejemplo — lo pides explícitamente con notación científica (0.1e0), obteniendo el comportamiento IEEE 754 esperado. El lenguaje no te lo impone: tú decides el trade-off conscientemente.

¿Qué significa esto para equipos de desarrollo en Perú y Latinoamérica?

Raku no es un lenguaje mainstream y probablemente no reemplazará a tu stack actual. Pero el problema que resuelve sí existe en producción, hoy, en sistemas reales que tu empresa usa o desarrolla.

Los errores de precisión de punto flotante son especialmente críticos en sistemas ERP, software contable, plataformas de e-commerce y cualquier aplicación que maneje dinero. En .NET, el tipo decimal existe exactamente por esta razón — pero muchos desarrolladores usan double o float por defecto sin entender la diferencia. En JavaScript, el problema es aún más silencioso porque solo existe un tipo numérico.

En proyectos de desarrollo que involucraron módulos contables y financieros, este tipo de decisiones de diseño — qué tipo de dato usar para representar montos — puede significar la diferencia entre un sistema confiable y uno que acumula errores de centavos que nadie detecta hasta que el auditor los encuentra. En Latinoamérica, donde muchas empresas aún están digitalizando procesos contables críticos, elegir bien los tipos de datos desde el inicio no es un detalle técnico: es una decisión de negocio.

¿Cómo aplica esto en tu empresa?

Si tu equipo desarrolla o mantiene software que maneja dinero, inventarios con decimales, o cálculos financieros, estas son las acciones concretas que puedes tomar hoy:

• Audita qué tipos de datos usa tu código para montos monetarios. En .NET usa siempre decimal, nunca double. En Python, considera la librería decimal del estándar. En JavaScript, evalúa librerías como big.js para operaciones financieras críticas.
• Revisa cómo tu ERP almacena y calcula decimales. Odoo, por ejemplo, tiene configuraciones de precisión decimal por categoría (moneda, cantidad, precio) que deben ajustarse correctamente para cada empresa.
• Establece tests automáticos para operaciones financieras. Un test que verifique que 0.1 + 0.2 == 0.3 en el contexto de tu negocio puede parecer trivial, pero detecta regresiones reales antes de que lleguen a producción.
• Documenta las decisiones de tipo de dato. El próximo desarrollador que toque ese código necesita saber por qué se usó decimal y no float. Sin documentación, ese conocimiento se pierde.

Raku nos recuerda que las decisiones de diseño de un lenguaje tienen consecuencias reales en el software que construyes con él. Conocer esas decisiones — y las alternativas — te hace un mejor ingeniero, independientemente del lenguaje que uses.

Conclusión

El hecho de que 0.1 + 0.2 no sea 0.3 en la mayoría de lenguajes no es una anécdota curiosa — es un recordatorio de que cada herramienta que elegimos tiene trade-offs implícitos que afectan la calidad del software que entregamos. Raku eligió la exactitud matemática como default. Otros lenguajes eligieron la velocidad. Ninguna elección es universalmente correcta, pero sí es importante que tu equipo la conozca y la tome de forma consciente.

En Consultoría-Ti ayudamos a equipos de desarrollo y empresas en crecimiento a tomar mejores decisiones técnicas — desde la arquitectura de software hasta la implementación de ERP. Si quieres revisar la calidad técnica de tus sistemas o necesitas un equipo que entienda tanto el negocio como el código, conversemos.

Fuentes y Referencias

Andrew Shitov — Raku: a Language Where 0.1 + 0.2 is 0.3 (Dev.to)

✨ Contenido generado con ContentFlow — Consultoría-Ti