Portada
mis comunidades
otras secciones
#9:
Recuerdo en clase de análisis numérico que el profesor nos hizo encuesta sencilla para ver lo que sabíamos de ordenadores y preguntó si al sumar 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 y preguntarle al ordenador si eso era igual a 1 que qué nos diría. La respuesta es que nos diría que no es lo mismo (en realidad depende del lenguaje de programación, tipo de dato utilizado, etc). Luego nos hizo la misma pregunta con 0.125+0.125+0.125+0.125+0.125+0.125+0.125+0.125, y en este caso la respuesta es que diría que sí que es igual. El motivo es que 0.1 no se puede escribir en base 2 con finitos decimales y sin embargo 0.125 sí.
editado:
subo captura de pantalla hecha con Maxima
#5:
#2 realmente no es un problema de los lenguajes de programación como dice la entradilla, es un problema del sistema de numeración binario, que no permite representar de forma exacta algunos números que si son representables en el sistema decimal.
Es lo mismo que ocurre en decimal por ejemplo con 1/3, por mucho que saquemos decimales nunca obtendremos una cifra exacta.
En primero de carrera vimos unos cuantos ejemplos, en la asignatura de sistemas digitales, que ahora mismo no recuerdo y me da pereza buscar.
Es lo mismo que ocurre en decimal por ejemplo con 1/3, por mucho que saquemos decimales nunca obtendremos una cifra exacta.
En primero de carrera vimos unos cuantos ejemplos, en la asignatura de sistemas digitales, que ahora mismo no recuerdo y me da pereza buscar.
Comentarios
Recuerdo en clase de análisis numérico que el profesor nos hizo encuesta sencilla para ver lo que sabíamos de ordenadores y preguntó si al sumar 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 y preguntarle al ordenador si eso era igual a 1 que qué nos diría. La respuesta es que nos diría que no es lo mismo (en realidad depende del lenguaje de programación, tipo de dato utilizado, etc). Luego nos hizo la misma pregunta con 0.125+0.125+0.125+0.125+0.125+0.125+0.125+0.125, y en este caso la respuesta es que diría que sí que es igual. El motivo es que 0.1 no se puede escribir en base 2 con finitos decimales y sin embargo 0.125 sí.
#9 dc da un 1.0 en el primero y en el segundo.
#12, ¿pero le has preguntado que si es lo mismo? Porque si no recuerdo mal, en java daba ambos 1.0, pero si le preguntabas que si era igual te decía que no, resulta que el 1.0 inicial era solo una representación. Otra forma de verlo es hacer
0.1+...+0.1-1
#15 No debe de ser lo mismo por obvias razones, si dan el resultado fraccional es por algo.
¿No falta un cero?
#1 Sólo si haces los cálculos en un procesador Intel Pentium del primer lote...
#17 Al menos ese no tiene el bug Spectre...
https://0.30000000000000004.com/
#teahorrounclick
Python 3.0:
1/10 + 2/10 == (1 + 2)/10 #?
False
La página muestra lo que aparece como resultado al usar diversos lenguajes: Ada, C, C++, C#, Common Lisp, Erlang, Fortran, Go, Roku, Java, MathLab, Mathematica, PHP, Perl, Python, R, TCL, Visual Basic y otros más esotéricos. En cada uno de ellos se calcula la suma (0,1+0,2) y se muestra el resultado (0,3; 0,30000000000000004; 0,300000; 0.300000012; 0.2999999999999999888977697537… hay de todo).
#2 Pues no tenía ni idea de esto, y parece que es así:
https://repl.it/repls/AngryAzureFibonacci
Meneo.
#2 realmente no es un problema de los lenguajes de programación como dice la entradilla, es un problema del sistema de numeración binario, que no permite representar de forma exacta algunos números que si son representables en el sistema decimal.
Es lo mismo que ocurre en decimal por ejemplo con 1/3, por mucho que saquemos decimales nunca obtendremos una cifra exacta.
En primero de carrera vimos unos cuantos ejemplos, en la asignatura de sistemas digitales, que ahora mismo no recuerdo y me da pereza buscar.
#5 En una empresa que curre, hablando con el "chico de oro" estaba empeñado en que ese problema no ocurría, ya ves la fauna del gremio.
#10 Si sabes lo que estás haciendo, no hay gran problema. Por ejemplo te puedes montar la aritmética recional exacta si es lo que necesitas. El problema ocurre cuando esta clase de genios se ponen a tomar decisiones sobre cosas que desconocen.
#5 En lenguaje como scheme por defecto toda fracción calculada usa un resultado fraccional, no con decimales. 5:10 te devolverá 1/2, si quieres el resultado decimal debes especificarlo.
#2 y esta es la razón principal por la que cuando antiguamente había que almacenar en base de datos importes con decimales se usaba el concepto (de hecho todavía se usa) de la "coma fija", que se entiende como un número entero en la que los X últimos dígitos son decimales. Para hacer cálculos no te queda más remedio que pasar a coma flotante pero una vez realizados se redondea al decimal que te interese y se vuelve a pasar a coma fija.
#6 ¿Para qué cálculos necesitas coma flotante? Tal y como lo explicas parece un type cast de los que deben dar error.
#14 pues para cualquier operación que necesitara trabajar con decimales. Si en dos variables enteras metes 3 y 2 respectivamente como hagas 3/2 no te va a dar 1,5 sino 1 (división entera). Si quieres que el cálculo sea una división normal has de convertir alguna de las 2 variables en float o double, es decir en coma flotante, para que la operación sea la deseada.
Y trabajar nativamente con comas flotantes tiene los mencionados problemas. Hoy en día los compiladores han mejorado y ya no se producen tantos "efectos ópticos desagradables" como antes, pero te aseguro que yo he visto operaciones simples como 4,0 * 1,0 = 3,99999999999 o 4,000000000001. A ver quien es el guapo que almacenaba eso así en la base de datos directamente....
Evidentemente he mencionado que esto era un problema del pasado y que la "coma fija" lo solucionaba. Hoy en día las bases de datos ya pueden trabajar con tipos de datos estilo "coma fija", pero el concepto en sí sigue siendo bastante utilizado.
Dos como
ochoceros y tenemos los mismo ceros.