Diferencias de JavaScript Math entre navegadores

ECMAScript define el objeto Math de JavaScript, pero no garantiza resultados idénticos bit a bit para todas las operaciones matemáticas en todos los navegadores. Los valores Number ordinarios usan representación binary64, por lo que el redondeo forma parte del modelo numérico. Muchas operaciones tienen un comportamiento especificado con precisión, mientras que algunas funciones matemáticas permiten aproximaciones dentro de las reglas del estándar. La aplicación debe expresar la precisión que necesita y probar ese contrato, no deducir un comportamiento universal del navegador a partir de un valor observado.

Estos detalles importan si un resultado determina una decisión, se guarda o pasa de un sistema a otro. Una expresión decimal no siempre se representa exactamente en binario, y el valor también puede pasar por análisis, conversión, formato y almacenamiento. Trata el recorrido completo como parte del contrato numérico de la aplicación. Un resultado adecuado para mostrar no necesariamente sirve para contabilidad o una decisión límite si no existe una regla explícita de redondeo.

Qué especifica ECMAScript

La distinción depende de la operación. Math.exp define el tratamiento exacto de NaN, infinitos y cero con signo, y permite un resultado aproximado por la implementación para las demás entradas. Math.round exige que un empate entre enteros se resuelva hacia infinito positivo y conserva las entradas no finitas y enteras. No es la misma regla que redondear un empate al dígito par en un cálculo financiero. Consulta el contrato concreto para distinguir una aproximación permitida de una expectativa errónea de la aplicación; no amplíes todas las tolerancias porque otra función de Math permita aproximaciones.

ECMAScript define las operaciones de Math y su comportamiento observable. La especificación del objeto Math establece requisitos concretos para cada operación. Algunos resultados quedan determinados estrictamente. Otras funciones, cuyos resultados reales normalmente no se pueden representar exactamente en binary64, permiten una aproximación acotada según el estándar. Eso no autoriza cualquier salida. Ante una diferencia que afecta a la aplicación, identifica la operación y consulta su requisito concreto en vez de generalizar desde un ejemplo.

La precisión finita explica muchos resultados que pueden parecer inesperados. El punto flotante binario almacena una combinación finita de potencias de dos, y muchas fracciones decimales habituales no tienen representación exacta en ese sistema. Por eso puede haber redondeo durante una operación o una conversión. Expresiones que parecen equivalentes también pueden redondear valores intermedios en órdenes distintos. Es un efecto normal de la representación, aunque una aplicación puede equivocarse al suponer igualdad decimal exacta o elegir un algoritmo inadecuado.

El código JavaScript añade otros límites numéricos alrededor de Math. El análisis de texto, las entradas JSON, la coerción implícita, la conversión de enteros a Number y la serialización de salida pueden afectar al valor antes o después de una operación matemática. Si dos navegadores parecen diferir, fija la entrada y la serialización, e inspecciona la operación entre ambas. De otro modo, un cambio en los datos de prueba o en la conversión puede confundirse con una diferencia del runtime. La versión del navegador no explica por sí sola todos los resultados numéricos.

El contrato también depende del dominio de la aplicación. Un total monetario, una coordenada gráfica y una puntuación estadística requieren rangos, precisión y errores aceptables distintos. Decide qué resultado es correcto para la tarea del usuario y expresa esa regla en una prueba. No conviertas en requisito accidental del producto una presentación decimal concreta o los últimos dígitos representables de una implementación, salvo que la aplicación dependa de ellos de forma explícita.

La aplicación debe hacer explícita la transición del valor matemático al valor que ve el usuario. Una cantidad calculada puede tener más precisión que la interfaz; el formato mostrado no debe reemplazar silenciosamente el valor guardado, salvo que esa sea la regla prevista. Una herramienta de medición puede conservar la precisión para cálculos posteriores y mostrar una lectura redondeada. Un flujo de pago puede necesitar, en cambio, un punto de redondeo definido antes de guardar el importe. Indica qué representación es la autoridad en cada límite y aplica la misma política a las exportaciones. Así, la pantalla, un archivo descargado y un cálculo posterior no discrepan por conversiones implícitas distintas. El contrato depende del dominio, por lo que una prueba de compatibilidad debe comprobar la regla de la aplicación, no imponer un número universal de decimales.

Cuidados de portabilidad

La política de redondeo debe decidirse en cada límite. Una aplicación puede conservar precisión internamente y redondear solo al mostrar. Un sistema que guarda cantidades decimales introducidas por usuarios también puede utilizar enteros escalados o una biblioteca decimal. Son contratos diferentes. Redondear demasiado pronto pierde información; aplazar el redondeo sin una regla puede producir totales que el usuario perciba como incoherentes. Define dónde se redondean los valores al guardarlos, intercambiarlos o presentarlos, y mantén esa decisión en todo el flujo.

El orden de las operaciones puede afectar a los resultados en punto flotante. Fórmulas equivalentes desde el álgebra no siempre redondean igual los valores intermedios con precisión finita. Una refactorización puede cambiar los últimos dígitos representables sin incumplir ECMAScript. Si la estabilidad numérica importa, elige un algoritmo adecuado al problema y pruébalo con entradas significativas. Solo considera una corrección específica de un navegador después de comprobar el requisito numérico y la especificación de la operación. De lo contrario, una solución alternativa puede conservar una expectativa accidental y empeorar el cálculo real.

Las comparaciones en límites requieren atención porque una pequeña diferencia de redondeo puede elegir otra rama. En tareas de elegibilidad, facturación o seguridad, define cómo tratar los empates y si la comparación ocurre antes o después del redondeo de presentación. Prueba valores a ambos lados del límite pertinente. También define cómo maneja la aplicación los valores no finitos, entradas no válidas y cero con signo cuando puedan aparecer. Rechazarlos, normalizarlos o informar de ellos debe ser una decisión explícita, no un efecto accidental de la serialización o el formato.

Las dependencias y las interfaces del host aportan sus propias reglas numéricas. Una biblioteca puede usar otro algoritmo o política de redondeo, y un servidor o base de datos puede representar los números de otra manera que JavaScript. Para los valores intercambiados, define la representación de transmisión y prueba el recorrido completo por análisis, cálculo, serialización y almacenamiento. Los enteros grandes y las cantidades decimales exactas pueden necesitar una representación explícita como texto o una estructura, en lugar de un número JSON genérico de punto flotante. El separador decimal localizado cambia la presentación, no el valor subyacente.

El mismo cuidado se aplica cuando los valores cruzan la frontera entre lenguajes. El lenguaje del servidor puede distinguir tipos enteros y decimales, y una columna de base de datos puede imponer su propia escala o rango. Convertir a Number de JavaScript y volver puede perder distinciones que el sistema de origen sí representaba. Decide si la interfaz transmite un entero, una cadena decimal o una estructura, y valídala en ambos extremos. Prueba los límites admitidos, incluido un recorrido completo por el almacenamiento. Si un valor solo sirve para mostrarlo, indícalo y no devuelvas la cadena formateada como entrada de cálculo. Un contrato explícito es más portable que las conversiones implícitas del navegador o del servicio. Documenta qué representación es la autoridad tras guardar y reutilízala al cargar. El usuario no debería ver que el valor redondeado mostrado pasa a ser la siguiente entrada de cálculo, salvo que esa sea una regla del producto. Los casos sintéticos de ida y vuelta cubren este límite sin incluir datos personales en las pruebas. Si un servicio rechaza un valor fuera de rango, devuelve una validación clara en vez de recortarlo silenciosamente. Estas decisiones conectan la precisión numérica con el comportamiento habitual de la aplicación y hacen que una prueba entre navegadores resulte útil para mantener el flujo.

Contexto de privacidad

Los resultados numéricos se pueden observar, pero un resultado de Math no establece la identidad del usuario ni el navegador que usa. Puede depender de las entradas, el código de la aplicación, la versión del runtime y el contexto de los datos. Tratar un valor como una identidad estable introduce supuestos de seguimiento injustificados y un comportamiento frágil. No recopiles resultados numéricos si la función no los necesita ni los unas a registros persistentes sin un propósito y una regla de retención claros.

Los diagnósticos deben ser proporcionales al problema. Si un usuario comunica un cálculo incorrecto, suele ser preferible una reproducción mínima con datos sintéticos que recopilar sus registros subyacentes. Registra la operación y la versión pertinente de la aplicación, no datos ajenos. Si el soporte necesita datos reales, obténlos mediante un proceso apropiado y controlado por el usuario, y define el acceso y la eliminación antes de recopilarlos. Mantén la evidencia temporal de ingeniería separada de la analítica de producto y elimínala cuando termine su finalidad de soporte.

La privacidad también depende de lo que ocurre alrededor del cálculo. Explica si los valores permanecen en la página, se envían a un servicio o se conservan después de la tarea. Una biblioteca estándar no decide esas prácticas. No unas diagnósticos con registros de cuenta o navegación sin relación. El soporte de compatibilidad puede necesitar la versión del navegador y el resultado funcional, pero eso no implica conservar todos los valores calculados por la aplicación. Los datos recopilados deben responder a la pregunta de soporte y no ampliarla.

Este tema trata de semántica numérica, no de precisión del reloj ni aleatoriedad con semilla. Esos asuntos se abordan por separado en señales temporales del navegador y comportamiento determinista del navegador. No describas un resultado de Math como identificador personal, modelo de dispositivo o prueba de una plataforma concreta sin evidencia. Una descripción precisa del flujo de datos de la aplicación es más útil que una promesa absoluta de privacidad o una afirmación de plataforma no respaldada.

Esta distinción importa cuando la aplicación recopila diagnósticos. Un informe de soporte que incluya un resultado debe explicar por qué hace falta y si contiene datos del usuario. A menudo la operación puede reproducirse con valores generados que no revelan sus registros. Si el soporte necesita la entrada real, limita la solicitud a ese caso y sigue el proceso habitual de consentimiento y eliminación. No conserves un historial de cálculos no relacionados solo porque sea fácil registrar números: podría revelar patrones de actividad sin ayudar a comprobar el contrato de la aplicación. Un diagnóstico temporal asociado a un caso concreto es más fácil de revisar y eliminar que un registro general de todos los valores calculados.

Pruebas numéricas reproducibles

Empieza por las operaciones que la aplicación usa realmente. Para cada una, define entradas representativas, el comportamiento esperado en el dominio y la regla de comparación. La igualdad exacta sirve cuando el contrato la requiere, por ejemplo para identificadores enteros o valores redondeados deliberadamente a una representación definida. Para cálculos aproximados, usa una tolerancia justificada por la tarea, la escala del resultado y el error esperado. Una tolerancia fija puede servir en un rango estrecho y ser inadecuada para valores de magnitudes muy distintas.

En un caso de prueba sintético pequeño, la regla de empate definida para Math.round hace que la entrada 2.5 produzca 3; cualquier otro resultado debe considerarse una aserción fallida, no un motivo para ampliar la tolerancia. Esto prueba esa regla estándar concreta, no una política de pagos: un contrato de facturación que use redondeo al par necesita su propia operación y expectativa.

En un formulario de pago que exige un importe, un campo vacío debe mostrar un mensaje visible de campo obligatorio y no enviar el formulario, no crear una transacción de importe cero. Para una factura guardada cuyo importe canónico es la cadena decimal 12.50, una actualización del formato solo en el navegador debe dejar intacto el importe guardado; si hay que cambiar el esquema almacenado, prueba una migración explícita con registros sintéticos antes de sustituirlo.

Prueba bordes relevantes además de valores habituales. Incluye entradas próximas a los límites del dominio, cero, valores negativos cuando estén permitidos, magnitudes próximas al rango admitido y casos no válidos o excepcionales. Los cálculos repetidos pueden acumular pequeños errores incluso cuando una operación aislada es aceptable, así que prueba la secuencia que realiza la aplicación. No se trata de catalogar todas las salidas posibles de Math, sino de cubrir las situaciones numéricas que pueden cambiar un resultado visible o incumplir el contrato del dominio.

Prueba la representación a lo largo de toda la interfaz. Si los valores se serializan, almacenan o intercambian con un servicio, verifica el recorrido completo, no solo el cálculo en el navegador. Los números JSON, cadenas formateadas, columnas de base de datos y bindings de otros lenguajes tienen reglas de representación propias. Define qué componente redondea y cómo se conserva la precisión. Separa el formato local del valor numérico para que un separador decimal no parezca una discrepancia aritmética. Si se requiere serialización determinista, especifica su codificación en la interfaz de la aplicación y normaliza solo lo permitido por el contrato.

Mantén los casos de prueba pequeños, sintéticos y vinculados a una regla visible para el usuario. Un caso límite debe explicar por qué importa; un valor grande debe indicar el rango que cubre. Al investigar un cambio, registra las revisiones del runtime y de la aplicación, y vincula la expectativa con el dominio, no con un resultado capturado en un solo equipo. Separa las pruebas unitarias de una operación de las pruebas del flujo de análisis, cálculo, formato y persistencia. Cada una detecta cambios distintos y orienta mejor el siguiente paso de mantenimiento. Los datos de prueba deben cubrir cómo entran los valores en la aplicación, incluidos espacios, separadores locales y campos vacíos. El parser debe aceptar una forma documentada o devolver una validación clara. Después prueba la función matemática con un valor conocido y actualiza la explicación visible cuando cambie la regla del dominio.

Si una versión cambia el flujo numérico, revisa también los datos guardados. Decide si los registros anteriores siguen siendo válidos, necesitan una migración única o deben conservar su representación original. Justifica la migración y pruébala con registros sintéticos; pide una acción al usuario solo cuando sea necesaria.

Revisar versiones del navegador

Si una actualización cambia una prueba numérica, conserva la revisión de la aplicación, la entrada y la aserción, y reduce el primer caso distinto. Comprueba si la operación está definida estrictamente o permite aproximación. Antes de atribuirlo al navegador, inspecciona las conversiones, versiones de dependencias, cambios de aplicación y serialización. Si la aserción era más estricta que el contrato del dominio, corrígela con una razón explícita. No amplíes tolerancias solo para silenciar una diferencia no explicada, pues podrías ocultar un problema real.

Una comparación controlada cambia una variable relevante cada vez. Una actualización del navegador puede coincidir con cambios en una biblioteca del sistema operativo, el paquete de la aplicación, los datos o el código compilado. Registra el entorno necesario para reproducir el flujo, pero evita recopilar detalles ajenos del equipo. Si la diferencia aparece después de actualizar una dependencia o la aplicación, compara esas revisiones por separado. No hay una regla general que atribuya un único comportamiento numérico a toda una familia de navegadores, operaciones y versiones.

El rendimiento es distinto de la corrección. Si un cálculo afecta a la respuesta de la interfaz, mide el flujo del usuario con datos representativos e indica la carga. No conviertas la duración en una etiqueta del navegador o del dispositivo. El hardware, la actividad de fondo, el estado de energía y los cambios del runtime influyen en el tiempo, mientras que una respuesta rápida no demuestra corrección numérica. Mantén las observaciones de rendimiento en pruebas propias y usa el contrato numérico para aceptar el comportamiento funcional.

Aplica la misma disciplina a bibliotecas numéricas, compiladores y datos almacenados. Una dependencia puede cambiar el algoritmo, un compilador puede alterar la evaluación y un valor persistido puede haber pasado por otra representación. Mantén una suite de regresión pequeña que explique el propósito de cada caso y revísala cuando cambien los requisitos del dominio o los navegadores admitidos. Antes de publicar, registra el flujo de la aplicación afectado y cualquier acción necesaria para el usuario, sin revelar valores específicos ni prometer identidad bit a bit universal. La revisión de versiones del navegador ayuda a separar los cambios del runtime de los cambios de la aplicación.

Si una publicación cambia un flujo numérico, revisa también los datos almacenados y los cálculos nuevos. Si antes se redondeaba en otra etapa, los registros existentes pueden seguir la política antigua. Decide si siguen siendo válidos, necesitan una migración puntual o deben conservar su representación original. No reescribas valores persistidos solo para que se parezcan a los resultados de un navegador nuevo. Es posible que el navegador no haya creado esos datos, y un cambio de formato de almacenamiento puede afectar a todos los clientes. Da a la migración una razón de dominio, pasos auditables cuando sea posible y una prueba con registros sintéticos. Solicita una acción al usuario solo cuando sea realmente necesaria y clasifica los fixtures por propósito para separar cambios del runtime, dependencias y aplicación.

Fuentes públicas

• ECMAScript: objeto Math
• MDN: Math