2012-04-26 15 views

Respuesta

1

Aunque la especificación del lenguaje ECMAScript 5.1 edición afirma que los números son valores primitivos correspondientes a IEEE 754 flotadores, lo que implica cálculos debe ser consistente:

http://www.ecma-international.org/publications/files/ecma-st/ECMA-262.pdf

4.3.19 valor Número

valor primitivo correspondiente a un formato binario de 64 bits de doble precisión Valor IEEE 754

NOTA Un valor numérico es un miembro del tipo Número y es una representación directa de un número.

Como BlueRaja puntos cabo, hay una especie de advertencia en la sección 15.8.2:

El comportamiento de las funciones acos, asin, atan, atan2, cos, exp, log, pow , el pecado, raíz cuadrada, y el bronceado no es precisamente especifica aquí ...

Significado, estos son por lo menos algunos casos en que el resultado de las operaciones con números depende de la implementación y por lo tanto pueden ser inconsistentes.

+0

No tengo ningún código específico, me preguntaba ... –

+2

Incorrecto. Ver mi respuesta –

+0

Esta respuesta es incorrecta. La misma máquina puede devolver resultados diferentes para una operación como x + y, incluso si xey son los mismos. La respuesta de BlueRaja es correcta. – lacker

3

Si asumimos que todos los proveedores de navegadores siguen las normas IEEE + ECMA y no hay ningún error humano durante la implementación, no puede haber ninguna diferencia.

+0

Sí, si cumplen con los estándares, todos se comportan de manera estándar. Los navegadores que no cumplen con IEEE/ECMA probablemente no valgan la pena usarlos de todos modos. – Romain

+0

Ah, ahora que ha agregado "ECMA", puedo eliminar mi respuesta y adelantar la suya. =) Más información para los lectores: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf especifica cómo deben comportarse todos los números de ECMAscript, generalmente en términos de varias especificaciones de IEEE. – ninjagecko

+0

Incorrecto. Ver mi respuesta –

11

Las otras respuestas son incorrectas. De acuerdo con el (sección 15.8.2) ECMAScript 5.1 specs

NOTA El comportamiento de las funciones acos, asin, atan, atan2, cos, exp, registro, prisionero de guerra, el pecado, raíz cuadrada, y fuego no se especifica precisamente aquí excepto para requerir resultados específicos para ciertos valores de argumento que representan casos límite de interés.

...

Aunque la elección de los algoritmos se deja a la aplicación, se recomienda (pero no especificada por esta norma) que las implementaciones utilizan los algoritmos de aproximación para IEEE 754 aritmética contenidas en fdlibm, la libre distribución biblioteca matemática de Sun Microsystems


Sin embargo, incluso si las implementaciones fueron especificado, los resultados exactos de todos operaciones de coma flotante serían todavía dependerán del navegador/arquitectura. ¡Eso incluye operaciones simples como multiplicación y división!

La razón es que IEEE-754 permite que los sistemas realicen cálculos de punto flotante de 64 bits en higher-precision than the result, lo que da lugar a resultados de redondeo diferentes a los sistemas que utilizan la misma precisión que el resultado. Esto es exactamente lo que x86 (Intel) architecture does, por lo que en C (y javascript) a veces podemos tener cos(x) != cos(y) even though x == y, ¡incluso en la misma máquina!

Ésta es una big issue for networked peer-to-peer games, ya que esto significa, si los cálculos de mayor precisión, no se pueden desactivar (como es el caso para C#), los juegos más o menos pueden no utilizan cálculos de punto flotante en absoluto . Sin embargo, esto normalmente no es un problema para los juegos de Javascript, ya que generalmente son cliente-servidor.

+0

Gran publicación, pero: en general (debido a la imprecisión) el uso == o! = Con flotadores no es una buena idea. Sin embargo, esto no significa que no pueda usar flotadores, solo significa que no use == o! =, Use los comparativos <= > = rangos adaptados a cualquier grado de precisión. – delicateLatticeworkFever

+0

@goldilocks tiene razón, de hecho (Math.tan (1) == Math.sin (1) /Math.cos (1)) produce un resultado falso ... –

+1

@ João: Sí, pero eso es ortogonal a su pregunta. Todo el mundo sabe que podríamos tener 'tan (1)! = Sin (1)/cos (1)', debido a imprecisiones de coma flotante. La pregunta no era si serían iguales, sino si 'tan (x)' siempre será exactamente lo mismo en todos los navegadores/máquinas para algunas 'x'. La respuesta a eso sigue siendo NO, pero no tiene nada que ver con la inexactitud de coma flotante, es porque 'tan (x)' no está definido con precisión en javascript, y porque IEEE-754 permite cálculos de precisión extendida. Si esas dos cosas no fueran ciertas, la respuesta sería sí, siempre es lo mismo. –

0

Mis dos centavos: @goldilocks notes y otros aluden a que no debe usar == o! = En números de coma flotante. Entonces, ¿qué quieres decir con "determinista"? Que el comportamiento es siempre el mismo en diferentes máquinas? Obviamente, esto depende de lo que quiere decir con "el mismo comportamiento".

Bueno, en un tonto nivel literal de "lo mismo", por supuesto que no, los bits físicos serán diferentes en, por ejemplo, Máquinas de 32 bits frente a máquinas de 64 bits. Entonces esa interpretación está fuera.

Ok, ¿se ejecutará cualquier programa con la misma salida en dos máquinas diferentes? En los lenguajes generales no, porque un programa C puede hacer algo con memoria indefinida, como leer desde un bit no inicializado.

Ok, ¿algún programa válido hará lo mismo en diferentes máquinas? Bueno, yo diría que un programa que usa == y! = En números de punto flotante es tan inválido como un programa que lee la memoria no inicializada. Personalmente, no sé si el estándar de Javascript reduce el comportamiento de == y! = En flotantes hasta el punto de que está bien definido si no es raro, por lo que si esa es su pregunta precisa, tendrá que ver las otras respuestas . ¿Puedes escribir código JavaScript que tenga un resultado no definido con respecto al estándar? Nunca lea el estándar (otras respuestas lo cubren un tanto), pero para mi interés, esto es discutible porque para empezar, los programas que producirían lo que ustedes llaman comportamiento no determinista son inválidos.

Cuestiones relacionadas