Cuando se evalúa la expresión:Haskell: salida inesperada para la expresión [0, 0.1 .. 1]
*main> [0, 0.1 .. 1]
realmente esperaba:
[0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1]
pero yo estaba bastante impresionada de ver la salida se
[0.0,0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0]
¿Por qué Haskell producir ese resultado tras ¿evaluación?
Esto es un resultado de la imprecisión de los valores floating point, no es particular de Haskell. Si no puede hacer frente a la aproximación inherente a punto flotante, puede utilizar Rational a un costo alto rendimiento:
> import Data.Ratio
Data.Ratio> [0,1%10.. 1%1]
[0 % 1,1 % 10,1 % 5,3 % 10,2 % 5,1 % 2,3 % 5,7 % 10,4 % 5,9 % 10,1 % 1]
Sólo para Hammer el clavo, aquí está Python:
>>> 0.3
0.29999999999999999
Y aquí está C:
void main() { printf("%0.17f\n",0.3); }
$ gcc t.c 2>/dev/null ; ./a.out
0.29999999999999999
Consulte this other post. Como dice, los números de coma flotante no son precisos en la CPU.
posible duplicado de [¿Por qué ghci dice que 1.1 + 1.1 + 1.1> 3.3 es verdadero?] (Http://stackoverflow.com/questions/2038647/why-does-ghci-say-that-1-1- 1-1-1-1-3-3-is-true) – Gabe
@TomMD, @Avilo: Gracias por la aclaración chicos, pero también quise decir que parece un poco raro que, por ejemplo, 0.3 .... 0004 y .5 , .6, .7 todos terminan en 0001 mientras que .2, .8 y .9 son "redondos". Simplemente no parece una imprecisión constante, no sé si me estoy explicando. – Carlos
@carlos Cuando sepa cómo se representa el punto flotante, esto tendrá mucho sentido. Tenga en cuenta que los valores exactos son sumas de dos a una potencia negativa. –