Portada
mis comunidades
otras secciones
#16:
Hay tres formas de trabajar con números reales, cada cual con sus ventajas e inconvenientes:
* Decimal: trabaja directamente con la representación en decimal del número. Evitan los errores de conversión a binario. En general, necesita más memoria para representar los números (el número de digitos) y su aritmética es muchíiiiisimo más lenta pero completamente precisa.
* Binario en coma flotante: convierte el número a representación binaria, introduciendo errores de redondeo al hacerlo. Necesita menos memoria (4 o 8 bytes) y su aritmética es rápida y bastante precisa. Y lo más importante, es la más sencilla de programar.
* Binario en coma fija: convierte el número a representación binaria (introduciendo un error), lo multiplica por una constante y guarda el resultado como un número entero. Su representación es la más compacta (2 o 4 bytes) y su aritmética la más rápida pero también la menos precisa.
Internet Explorer, Firefox, Python o PHP, todos utilizan representación en coma flotante y todos obtienen como resultado interno 5.10000000000000053290705182007513940334320068359375. La diferencia es la cantidad de decimales que muestran por pantalla. Si el resultado lo redondeas a 14 decimales o menos se muestra 5.1 y si se redondea a 16, se muestra 5.1000000000000005.
* Decimal: trabaja directamente con la representación en decimal del número. Evitan los errores de conversión a binario. En general, necesita más memoria para representar los números (el número de digitos) y su aritmética es muchíiiiisimo más lenta pero completamente precisa.
* Binario en coma flotante: convierte el número a representación binaria, introduciendo errores de redondeo al hacerlo. Necesita menos memoria (4 o 8 bytes) y su aritmética es rápida y bastante precisa. Y lo más importante, es la más sencilla de programar.
* Binario en coma fija: convierte el número a representación binaria (introduciendo un error), lo multiplica por una constante y guarda el resultado como un número entero. Su representación es la más compacta (2 o 4 bytes) y su aritmética la más rápida pero también la menos precisa.
Internet Explorer, Firefox, Python o PHP, todos utilizan representación en coma flotante y todos obtienen como resultado interno 5.10000000000000053290705182007513940334320068359375. La diferencia es la cantidad de decimales que muestran por pantalla. Si el resultado lo redondeas a 14 decimales o menos se muestra 5.1 y si se redondea a 16, se muestra 5.1000000000000005.
#19:
especificacion javascript 1.1:
Apartado 11.6.3 Applying the Additive Operators ( +,- ) to Numbers
The result of an addition is determined using the rules of IEEE 754 double-precision arithmetic.
IEEE 754 doble precision (64 bits) es segun wikipedia:
1 bit pal signo
11 bits para la cifra significativa
52 bits para los decimales
lo cual kisir:
5.2 en bits = 0 10000000001 0100110011001100110011001100110011001100110011001101
o sea 1.0100110011001100110011001100110011001100110011001101 * 4
0.1 en bits = 0 01111111011 1001100110011001100110011001100110011001100110011010
o sea 1.1001100110011001100110011001100110011001100110011010 * 0.625
restamos (hay que desplazar el segundo):
1.0100011001100110011001100110011001100110011001100111 * 4
lo cual me da 5.1000000000000005
la especificacion de ecmascript no dice k tenga k redondear, asi k explorer simplemente es el unico que esta incumpliendo el standar. pk sale bien? Pues no me pienso poner a probar todas las combinaciones para saber k metodo esta usando pero probablemente es porke tiene menos precision, si a 5.1000000000000005 le quitas un par de cifras se queda en 5.100000000000, que se redondea a 5.1. parece k esta bien pero no. puede ser un resultado mas deseable, pero javascript no garantiza precision de punto flotante, en un lenguaje generico se prefiere predecibilidad y k no haga cosas a tu espalda k tu no le has pedido
bastante triste lo de kriptopolis por cierto, se supone k escriben de seguridad y polladas de esas y no se dan cuenta de esto?
Apartado 11.6.3 Applying the Additive Operators ( +,- ) to Numbers
The result of an addition is determined using the rules of IEEE 754 double-precision arithmetic.
IEEE 754 doble precision (64 bits) es segun wikipedia:
1 bit pal signo
11 bits para la cifra significativa
52 bits para los decimales
lo cual kisir:
5.2 en bits = 0 10000000001 0100110011001100110011001100110011001100110011001101
o sea 1.0100110011001100110011001100110011001100110011001101 * 4
0.1 en bits = 0 01111111011 1001100110011001100110011001100110011001100110011010
o sea 1.1001100110011001100110011001100110011001100110011010 * 0.625
restamos (hay que desplazar el segundo):
1.0100011001100110011001100110011001100110011001100111 * 4
lo cual me da 5.1000000000000005
la especificacion de ecmascript no dice k tenga k redondear, asi k explorer simplemente es el unico que esta incumpliendo el standar. pk sale bien? Pues no me pienso poner a probar todas las combinaciones para saber k metodo esta usando pero probablemente es porke tiene menos precision, si a 5.1000000000000005 le quitas un par de cifras se queda en 5.100000000000, que se redondea a 5.1. parece k esta bien pero no. puede ser un resultado mas deseable, pero javascript no garantiza precision de punto flotante, en un lenguaje generico se prefiere predecibilidad y k no haga cosas a tu espalda k tu no le has pedido
bastante triste lo de kriptopolis por cierto, se supone k escriben de seguridad y polladas de esas y no se dan cuenta de esto?
#8:
#7 Un contable belga cajero en un banco de aquellos lares, allá por los años 70 (creo), descubrió que su banco realizaba las operaciones contables con una exactitud de 5 cifras decimales y redondeando como dicta la norma del redondeo del euro actual. Este tipo, hábil matemático y aficionado a esas cosillas de programar, decidió reprogramar el software que usaban en la oficina para que los cálculos hechos desde su terminal se efectuasen no con 5, sino con 6 cifras decimales, y embolsarse la millonésima parte de moneda que "sobraba" de cada operación. A los cinco años, le detuvieron por una estafa por valor de cientos de millones de las antiguas pesetas. Y hablo de los años 70.
Ahora imagínate lo que sucedería si las aplicaciones que usan los bancos en España para las "bancas virtuales", en mayoría Java, tuvieran este mismo "error". ¿Tu crees que se equivocarían a favor o en contra del cliente?.
Ahora imagínate lo que sucedería si las aplicaciones que usan los bancos en España para las "bancas virtuales", en mayoría Java, tuvieran este mismo "error". ¿Tu crees que se equivocarían a favor o en contra del cliente?.
#1:
¿Alguien sintió hablar de la precisión en punto flotante y de las diferencias que se pueden apreciar según el formato de impresión?
Comentarios
Hay tres formas de trabajar con números reales, cada cual con sus ventajas e inconvenientes:
* Decimal: trabaja directamente con la representación en decimal del número. Evitan los errores de conversión a binario. En general, necesita más memoria para representar los números (el número de digitos) y su aritmética es muchíiiiisimo más lenta pero completamente precisa.
* Binario en coma flotante: convierte el número a representación binaria, introduciendo errores de redondeo al hacerlo. Necesita menos memoria (4 o 8 bytes) y su aritmética es rápida y bastante precisa. Y lo más importante, es la más sencilla de programar.
* Binario en coma fija: convierte el número a representación binaria (introduciendo un error), lo multiplica por una constante y guarda el resultado como un número entero. Su representación es la más compacta (2 o 4 bytes) y su aritmética la más rápida pero también la menos precisa.
Internet Explorer, Firefox, Python o PHP, todos utilizan representación en coma flotante y todos obtienen como resultado interno 5.10000000000000053290705182007513940334320068359375. La diferencia es la cantidad de decimales que muestran por pantalla. Si el resultado lo redondeas a 14 decimales o menos se muestra 5.1 y si se redondea a 16, se muestra 5.1000000000000005.
#7 Un contable belga cajero en un banco de aquellos lares, allá por los años 70 (creo), descubrió que su banco realizaba las operaciones contables con una exactitud de 5 cifras decimales y redondeando como dicta la norma del redondeo del euro actual. Este tipo, hábil matemático y aficionado a esas cosillas de programar, decidió reprogramar el software que usaban en la oficina para que los cálculos hechos desde su terminal se efectuasen no con 5, sino con 6 cifras decimales, y embolsarse la millonésima parte de moneda que "sobraba" de cada operación. A los cinco años, le detuvieron por una estafa por valor de cientos de millones de las antiguas pesetas. Y hablo de los años 70.
Ahora imagínate lo que sucedería si las aplicaciones que usan los bancos en España para las "bancas virtuales", en mayoría Java, tuvieran este mismo "error". ¿Tu crees que se equivocarían a favor o en contra del cliente?.
especificacion javascript 1.1:
Apartado 11.6.3 Applying the Additive Operators ( +,- ) to Numbers
The result of an addition is determined using the rules of IEEE 754 double-precision arithmetic.
IEEE 754 doble precision (64 bits) es segun wikipedia:
1 bit pal signo
11 bits para la cifra significativa
52 bits para los decimales
lo cual kisir:
5.2 en bits = 0 10000000001 0100110011001100110011001100110011001100110011001101
o sea 1.0100110011001100110011001100110011001100110011001101 * 4
0.1 en bits = 0 01111111011 1001100110011001100110011001100110011001100110011010
o sea 1.1001100110011001100110011001100110011001100110011010 * 0.625
restamos (hay que desplazar el segundo):
1.0100011001100110011001100110011001100110011001100111 * 4
lo cual me da 5.1000000000000005
la especificacion de ecmascript no dice k tenga k redondear, asi k explorer simplemente es el unico que esta incumpliendo el standar. pk sale bien? Pues no me pienso poner a probar todas las combinaciones para saber k metodo esta usando pero probablemente es porke tiene menos precision, si a 5.1000000000000005 le quitas un par de cifras se queda en 5.100000000000, que se redondea a 5.1. parece k esta bien pero no. puede ser un resultado mas deseable, pero javascript no garantiza precision de punto flotante, en un lenguaje generico se prefiere predecibilidad y k no haga cosas a tu espalda k tu no le has pedido
bastante triste lo de kriptopolis por cierto, se supone k escriben de seguridad y polladas de esas y no se dan cuenta de esto?
¿Alguien sintió hablar de la precisión en punto flotante y de las diferencias que se pueden apreciar según el formato de impresión?
¿alguien ha votado negativo mi comentario #6 porque decir que soy vago parar mirar el código fuente de Firefox? Pues nada, nada, mañana me lo miro.
El Internet Explorer no se sabe la tabla de multiplicar del 1
javascript:5.1000000000000005*1
- En IE 5.1
- En firefox 5.1000000000000005
Para #22, no hay excusas de mal pagador ni nada de eso. La inmensa mayoría de los lenguajes de programación usa cálculos en coma flotante binaria. Utilizar la coma flotante tiene ventajas: los cálculos son rápidos, siempre se utiliza el mismo espacio para almacenar un número y se pueden almacenar números muy grandes y muy pequeños perdiendo poca precisión pues la representación se centra en las N cifras binarias más significativas. Algunas consecuencias de esto son:
-Algunos números decimales sencillos tienen representaciones binarias no exactas: por ejemplo, 0,1 decimal es 0,000110011001100110011001100110011....... (se repite el grupo 0011 hasta el infinito)
-Cualquier operación que exceda la precisión de la representación acumula errores
-Un programa jamás debe hacer comparaciones del tipo "if x==0.1 ..." porque esa precisión no está garantizada
-Si se quieren resultados exactos o con muchas cifras significativas, hay que usar otras representaciones más lentas y que consumen más memoria
En resumen, la representación de coma flotante es muy útil, pero hay que saber sus limitaciones. En el caso que nos ocupa, los dos navegadores (y casi cualquier aplicación que utilicemos) almacenan los números en coma flotante. El IE simplemente redondea las últimas cifras significativas al imprimir en decimal. Esto a veces puede darnos resultados mejores, pero a veces también da resultados peores. Por ejemplo:
Expresión: javascript: (5.2-5.1)*1000000000000000
Resultado correcto: 100000000000000
Firefox: 100000000000000.53 (error +0,53)
Internet Explorer: 100000000000001 (error +1)
Conclusión: el caso expuesto no representa un error de cálculo en Firefox. Aunque el resultado quede "feo" a la vista, el error que se produce en el ejemplo inicial solo es de 0,0000000000000005, es decir, 5E-16. Para que nos hagamos una idea, el tamaño de un átomo es de aproximadamente 1E-10 metros. O sea, que si cometemos ese error al medir algo, nos estamos equivocando por unas pocas millonésimas de átomo, lo que es más que suficiente para la inmensa mayoría de las aplicaciones.
¡Magnifico! Ya solo le queda a IE el interpretar correctamente las normas W3C.
#3 prueba esta y cuenta cifras decimales. javascript:52/35
En firefox 16 decimales en IE 14, cuenta en que posición decimal esta el el 5 y te darás cuenta de que no es que uno lo calcule bien, eso es cosa de lo que dice #1,que es algo básico tras tres horas de programación cuando te dicen es mejor usar enteros cuando si puedes porque los reales tienen problemas de precisión al comparar... O simplemente sabiendo binario, te das cuenta de que no se pueden representar ciertos números sin aproximaciones. Es tan básico que si no lo sabes, es mejor que saltes estas noticias. Mejor que llamar pedante a la gente si desde luego.
Viendo lo que se considera pedantería, debería explicar que si un programa calcula 14 decimales y son 0 entonces los borra por aquello de los 9 a la izquierda, si un programa encuentra un 5 en la posición 16 que el otro no leía pues no elimina 0.
De todas formas, lo único que se puede sacar es que firefox muestra más cifras e internamente IE trabaja con más de esas 14 cifras pues en el ejemplo que he usado muestra valores redondeados y no truncados.
#31, con todo el cariño del mundo, el resultado no está mal. Es un problema de las limitaciones de la computación. Los números con coma flotante pierden precisión (¡normal! ¿qué notación podría representar infinitos números?). Internet Explorer, de pura casualidad, al redondear acierta. Pero las casualidades no se pueden tomar como virtudes, porque a veces funcionan y otras no.
Es mejor atenerse a los estándares, seguir las reglas, para que el programador sepa lo que se va a encontrar. Para pitonisas tenemos a Aramis Fuster.
#17 te voto positivo y te recuerdo que mañana es sábado
#5 y #5, ya te han explicado varios comentarios el porqué la noticia es erróna.
El estándar javascript para representación y operaciones de punto flotante es el IEEE 754 (http://en.wikipedia.org/wiki/IEEE_floating-point_standard). El resultado que presentan todos los navegadores que muestran el "5.1000000000000005" es el correcto cuando se muestra a la máxima precisión.
Si para imprimir lo redondeas o cambias la precisión es otra cosa, pero no significa que esté mal, simplemente que lo imprimes con menos precisión.
Prueba: javascript:(5.2-0.1).toFixed(1)
#8 Mira que hace años que no la veo, pero ese también era el argumento de Superman III ¿no?
Meneada porque efectivamente es noticia que IE sea mejor en algo al resto de navegadores
La clave del artículo está casi al final:
[...] semejante falta de precisión en las operaciones de coma flotante no lleva a ningún sitio, pero no deja de resultar curioso que, por una vez, Explorer supere en algo a toda la peña.
No se si alguien lo habrá comentado ya, pero IE hace el cálculo de la misma forma que los demás, lo que pasa es que muestra menos decimales, y elimina los ceros de la derecha, no hay más. Como bien apunta #30, la función toFixed muestra el resultado con el número de decimales que le digamos, y si a IE le decimos que muestre 16 decimales:
javascript:(5.2-0.1).toFixed(16)
Pues eso, no es oro todo lo que reluce.
Que alguien me corrija si no estoy en lo cierto, pero yo deduzco que será por la versión/dialecto de ECMAScript (http://en.wikipedia.org/wiki/ECMAScript#Dialects) que usa cada uno de esos navegadores.
Por ejemplo, la mayoría de navegadores usa "JavaScript" y en cambio el Explorer usa "JScript", que es una implementación de Microsoft del ECMAScript.
Bueno, esto son deducciones mías, si voy errado, no me acribilléis
Saludos.
No es un problema de python ni de firefox, ni de opera...
Es un problema de tipos, totalmente de acuerdo con #1, me parece mentira que nadie haya leído sobre la precisión de double y float.
Que alguien pruebe javascript:1+1e-15 y diga a ver que sale.
por dios, que lo haga alguien con un pentium original,
a ver que sale
#38 #1 es verdad.... como todos los que visitamos meneame trabajamos en la informatica y estudiamos informatica, lo veo una chapuza por parte nuestra no saber estas cosas...quien me mandaria a mi estar en el conservatorio sin saber que el firefox me mide la viola con una precision de 16 ceros en coma flotante(o lo que sea...)
vamos hombre
La verdad es que me pregunto por qué será... (y desgraciadamente me siento vago como para no bajarme el código fuente de Firefox para mirarlo...)
Vaya patinazo...
Y el comentario en Kriptópolis: http://www.kriptopolis.org/explorer-aprueba-matematicas#comment-24032
"PS: en mi firefox con linux javascript:850.0*77.1 da un resultado de 65534.99999999999. Arrieritos somos y en el camino nos encontraremos"
#36
Pues la del 0,1 sí se la sabe:
javascript:0.1*0.1
IE: 0.01
FF: 0.010000000000000002
#2 Supongo que la noticia no es que el perro muerda al hombre, sino que el hombre muerda al perro
#1 Pues seguramente algunos sí y algunos no. Pudiendo haber tomado la actitud de compartir tu conocimiento con los demás, has tomado la opción de dejar un comentario pedante. Allá tú.
La operación no está mal, es un "error" normal en las operaciones de coma flotante. Generalmente es tan pequeño que suele dar igual.
Hay casos en los que puede dar problemas, por ejemplo ese pequeño error si se va acumulando puede dar lugar a un error mayor, para eso muchos lenguajes de progamación y bases de datos tienen tipos de datos que te hacen las operaciones exactas.
Por ejemplo el Python tiene el módulo "Decimal" que sirve para esto
Y si escribes
javascript:5.2-0.100000000000005
¿Quien aprueba? eh eh
Aca lo importate es que muchos niños en Haiti mueren de hambre diariamente. Que va!
#19, #23 No he trabajado mucho con Firefox y Explorer (dos añitos nada más), pero la impresión que me queda tras ello es que Firefox hace lo que dicen los estándares (casi siempre, que no siempre) y Explorer hace lo más lógico (que no siempre es lo que dice el estándar).
Ejemplo, la función getYear() de JavaScript. Según el estándar hay que devolver el año - 1900. Lo cual queda guay para el siglo 20, (1999 = 99) pero raro de narices en el siglo 21 (2007 = 107.. wtf?). Firefox sigue el estandar, Explorer pasa y devuelve 2007 y listo.
En mi opinión el que hace lo correcto es el Firefox, por seguir el estándar, pero los que hicieron el estandar también podían haberlo hecho mejor...
Pasa lo mismo con XML, con CSS...
#32 Según tus comentarios estos países no son civilizados:
http://es.wikipedia.org/wiki/Coma_decimal#Pa.C3.ADses_que_usan_el_punto_decimal
Si tú lo dices...
#42 Como muchos niños de Haití mueren de hambre diariamente ya no podemos pensar en nada más?
#12 Lo que saca firefox tampoco es erroneo del todo... 1+1=2; 0.999= 1??
1+1=2; 0.999= 1??
es.wikipedia.org#35, ya han dado muchos enlaces en los que explican cómo funciona la representación de números de coma flotante. Da igual que sean racionales o no lo sean. La infinitud no viene por el número de dígitos de los números, sino porque tanto el conjunto de los racionales como (por extensión) el de los reales son conjuntos densos (http://wmatem.eis.uva.es/~matpag/CONTENIDOS/Reales/reales.htm#Densidad%20del%20orden), y el número de bits que utilizamos para representar un número es finito (32 bits, 64, o los que sean dependiendo del estándar que estemos usando).
Pero a quién coño le importa eso si todos usamos navegadores diferentes?
#8 pues no me digas mas ,se han enterado por que aplicaban al cliente el calculo de firefox
.
#9 si en la peli de super man esta la parodia del cheque con la tonteria de los centimos
#32 Ese es exactamente el problema que denuncio: que haya gente que considere que hacer una sencilla resta de forma correcta sea pillarsela con papel de fumar.
#36 Normal usando la version 5.1 x D prueba la 7.0
el maxthon tambien devuelve el resultado correcto, pero supongo que sera porque usa el motor del explorer, no? ¿?
#46 Exacto, usa el motor del Explorer, por eso hace lo mismo que hace el Explorer.
Pues Python también suspende:
ActivePython 2.5.0.0 (ActiveState Software Inc.) based on
Python 2.5 (r25:51908, Mar 9 2007, 17:40:28) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 5.2
5.2000000000000002
>>> 5.2-0.1
5.1000000000000005
#33 No es un problema de limitación de computación. Ni 5.2 ni 0.1 son números reales, sino racionales, representables ambos por un número finito de bits con total precisión y también representable, por ello, el resultado de su resta con total precisión.
#31:puestos a pillarsela con papel de fumar, yo veo un error bastante más grave. El punto no representa decimal en el mundo civilizado y según los estándares. Esta mal y punto.
Aún así el error es mucho menor que en excel:
Excel 2007: Bug en la multiplicación [Inglés]
Excel 2007: Bug en la multiplicación [Inglés]
it.slashdot.orgExcel 2007: =850*77.1 = 100000
firefox: javascript:850*77.1 = 65534.99999999999
Correcto: 65535
Si el ganador fuese otro no se votaría ni irrelevante, ni cansina, ni 20000 cosas más (ojo, yo uso Firefox)
Todo esto me recuerda al chiste ese del ingeniero, el matemático y no sé quién más, que ante la pregunta "¿Cuánto son dos más dos?" responden de diferentes formas. El ingeniero dice que el resultado es 3.999999999999 y el matemático dice que acaba de demostrar que la respuesta existe y está acotada.
Hay un cuento corto de Asimov (no recuerdo su nombre) donde habla de un futuro en el que la gente 'olvida' las matemáticas, y de hecho confían en los robots para las operaciones más sencillas. De hecho, la gente de ciencias de ese futuro desarrolla toda una serie de nuevos paradigmas, donde las matemáticas más básicas son algo extraño y aleatorio e inaccesible por el ser humano.
Con todo el cariño del mundo: venga va, no me toquéis los cojones. El resultado está mal y punto. No nos equivoquemos entre lo que es una explicación de algo (Javascript trabaja con coma flotante y pierde resolución) con una justificación de algo (cumplo el estándar y hago las operaciones bien, por lo tanto el resultado está bien).
el fire da 5.1000000000000005
explore da 5.1
para calculos de la nasa es eso que necesita tanta precision??????
Menuda gilipollez.
Pero bueno, y todavía con excusas de comas flotantes, de formato.. Está mal y punto. Algunos parece que nos quieren hacer ver que está bien, que en la vida real 5.2-5.1=5.1000000000000005. Dejarse de formatos y excusas de mal pagador.
¿y qué querian? lo primero que se aprende en un curso de programación es a hacer operaciones noñas con números noños...
#4 Y no sólo #1 ha sido pedante, sino que también ha votado errónea, lo que demuestra que ni se ha molestado en comprobar que lo que se dice es totalmente cierto.
Hombre, está claro que no estamos hablando de un bug como el de Excel, pero no deja de ser algo curioso.
#1 Sí, listillo, pero ahora explica por qué Explorer es el único que acierta.