Ufa... quería ser yo quien les aclare las dudas. No se vale
Como te ha dicho Sergio, no es que Double falle sino la cantidad de dígitos que tu has puesto; que excede a lo que Double es capaz de registrar. Si te fijas bien amigo, tu número si ha podido ser calculado con precisión exacta a 15 decimales. Los decimales que le siguen corresponden a esos decimales basuras que llama Sergio.
Como bien dices, en aritmética de punto flotante los números son expresados como mantisa y exponente. La FPU para facilitar algunas operaciones matemáticas normaliza la mantisa cuando lo considere oportuno y mantiene a la mantisa intacta, como sigue siendo matemática el cálculo será exacto como si nunca se hubiera hecho alguna normalización (es decir, asumir un x 10
0).
Como yo he dicho, la precisión de los puntos flotantes está en la cantidad de dígitos decimales, está establecido por el estándar IEEE que Double tenga 15/16 decimales (normalmente tiene 15 decimales, sólo para ciertos números especiales es que Double llega a tener 16).
Pero como este espacio es finito sólo puede asumir ciertos valores, y resulta ser que no todos los números pueden ser expresados en forma exacta en el sistema binario.
Por ejemplo, 0,333... o hasta incluso 0,01 no es posible. Es por ello que debido a la cantidad de decimales es que no se puede tener mejor precisión para representar al número real.
Además, la FPU para ofrecer garantías de que los cálculos se realicen exactamente redondeados y sean lo más exactos mantiene 2 decimales ocultos, de forma interna, uno que está destinado para llevar acarreo y el otro a modo de guarda o guardían para los números desnormalizados por lo que internamente Double tiene capacidad para 2 decimales más. Así hay garantías de que va a funcionar la operatoria. Luego cuando se regresa el valor estos decimales ocultos se quitan.
Lo que tu ves al pedirle que te muestre más decimales de lo que puede es justamente esos decimales. El compilador interpretó al Double como Extended y eso es lo que te devolvió... cuando hizo el paso de un tipo al otro fue necesario llevarlo a la precisión del segundo. Llevándose consigo esos decimales basuras que superaron su precisión.
Debido a que se quita ese decimal interno, es que podemos afirmar que el número obtenido es lo más aproximado posible más un 0,5 ulps.
Cambia el tipo Double por un Extended en el código de ejemplo y observa
Ahora vuelve a ponerlo como Double y pidele que te muestre 15 decimales. ¿Ves algo fuera de lo normal? Claro que no.
Sergio, NaN no significa lo que estás pensando... NaN es eso: ¡Not is a Number!. Es uno de los números especiales, junto a +/-INF y el CERO. De hecho en realidad tenemos dos tipos de NAN, QNAN y SNAN.
Creo que al número que tu estás buscando es el valor por defecto, establecido como constante para el valor de epsilon o tolerancia:
const
FuzzFactor = 1000;
ExtendedResolution = 1E-19 * FuzzFactor;
DoubleResolution = 1E-15 * FuzzFactor;
SingleResolution = 1E-7 * FuzzFactor;
O lo que es lo mismo 1E-12
Justamente lo que comenté antes. La precisión estándar que asume la mayoría para sus cálculos dejando los 2/3 decimales como "peligrosos".
Lo que quiero decirles a todos es que no teman a los puntos flotantes, si hay que respetarlos y aprender a usarlos. Les pido a todos que lean las fuentes que he dejado en
mi hilo cuando me surgieron todas estas dudas. En especial y de sobre manera el artículo "Lo que todo informático debe saber sobre aritmética de punto flotante".
Y no está demás amigarse con el Cálculo Numérico y la teoría del error relativo y absoluto; aprender a medir con que precisión se han de tomar los números, y a calcular el error que se comete cuando se suma, resta, multiplica, divide o se calculan raíces. Esto nos puede ayudar a establecer las pautas necesarias y hacer un mejor seguimiento de lo que pasa dentro de nuestros algoritmos y prepararnos para controlar las situaciones.
No es nada fácil ni hay un único método en como hacer un seguimiento y control a un algoritmo o ecuación pero con algunas guías uno se puede dar mañas.
Saludos,
.
