Interpretación de tipo de dato flotante

[[mlara]]

No sé, pero recordé una ocasión en la que pedí que no me hablaran de Firebird cuando abordé un caso relacionado con InterBase, y no faltó quien lo hizo. Acaso la solución era migrar todo un sistema con miles de líneas de código fuente y una implementación de base de datos que usaba y explotaba características propias de InterBase? Quiero decir con esto, y volviendo al tema, que creo las respuestas no son del todo apropiadas ya que no abordan el tema tal y como está planteado, razón por la cual voy a intentar explicarlo de otra manera, para lo cual parto nuevamente desde el comienzo:

La sentencia:

Código SQL [-]
SELECT IIF(8.99 = CAST(8.99 AS DOUBLE PRECISION), 1, 2) FROM RDB$DATABASE

, si la probamos en todas las instalaciones de Firebird y equipos que queramos, nos debe dar como resultado 1, cierto?

Veamos: el número 8.99 tiene su forma binaria tanto en 32 bits como en 64 bits (la podemos ver aquí: http://www-2.dc.uba.ar/materias/oc1/...at_conver.html)

Si voy a la representación binaria de precisión simple (32 bits) y luego hago la conversión nuevamente a punto flotante obtengo el número: 8.9899998

Si voy a la representación binaria de precisión doble (64 bits) y luego hago la conversión nuevamente a punto flotante obtengo el número: 8.99

Son diferentes, por supuesto. Ahora, si observamos nuevamente la consulta la pregunta es: aún esperamos 1 como resultado? Yo diría que sí, o acaso 8.99 no es igual a 8.99? Aún haciendo uso del CAST en el segundo.

Pero no nos apresuremos...

Obviamente Firebird hará internamente las conversiones del caso para poder comparar los números expresados en forma binaria (o hexadecimal). Entonces, si supongo que el CAST obliga a Firebird a expresar el 8.99 con precisión doble (de 64 bits), qué pasa con el primer 8.99, que no tiene CAST? Se expresará como un dato de punto flotante con precisión simple? Firebird lo "elevará" y expresará como un dato de punto flotante de precisión doble, dado el tipo de dato del número al lado derecho en la expresión condicional?

Antes de continuar, quiero recordar que la exposición del tema se debe a que, al ejecutar la consulta de este post en "mil computadores" ... obtengo un 1 como resultado, menos en uno de ellos. Qué sucede en ese equipo?

Ahora, si a esto le sumamos el hecho de que el sistema en cuestión viene funcionando hace más de 10 años y que se trata de un sistema robusto, en producción, usado por muchos clientes que nunca han tenido problemas en este sentido, la solución obviamente no es morirse cambiando los tipos de datos DOUBLE PRECISION a NUMERIC, salvo que todas las plataformas del mundo hubiesen "mutado" misteriosamente y de repente todo funcionara mal (hago la salvedad de que esto sí podría ser posible si alguna actualización del sistema nos quisiera hacer pasar un mal rato).

[Casimiro Notevi]

Es que no tiene nada que ver con firebird o interbase. Es igual en todos los sistemas.

[[mlara]]

A veces cuando quiero hablar de si las cosas son o no son me voy a la taberna... Casimiro, de qué se trata esto? Yo expongo un caso que me parece interesante discutir. Podría plantear las cosas de otra manera, podría preguntar de qué manera Firebird hace las conversiones, y luego las comparaciones? De qué depende? Y no todos los sistemas o los lenguajes o sistemas las hacen igual, pero no quiero desviarme del tema. Al final sólo creo que el tema podría tratarse de verdad, un poco en profundidad.

[[mlara]]

egostar, yo diría que no tiene nada qué ver con el procesador. Aún así en el primer post de este hilo expuse las características del equipo en el que sucede.

[mamcx]

Puede que si:

http://randomascii.wordpress.com/201...-compare-them/

Mas detalles en:

http://randomascii.wordpress.com/201...int-precision/

En resumen:

IIF(8.99 = CAST(8.99 AS DOUBLE PRECISION), 1, 2)

Es una comparación/afirmación incorrecta. Por eso te puse el link de http://programmers.stackexchange.com...-pitfalls?rq=1 donde se muestra que seria mejor que los lenguajes no implementaran la igualdad para floats.

Tambien ahi estaba:

Warning: The floating-point type System.Double lacks the precision for direct equality testing.

Que no es firebird pero da una idea.

En el momento que hay un float, no esperes resultados predecibles si cambias de compilador, CPU o arquitectura, a menos que uses una libreria que de esas garantias.

Por ejemplo en:

http://gafferongames.com/networking-...t-determinism/

People even report different results on the same machine from run to run, and between debug and release builds. Other folks say that AMDs give different results to Intel machines, and that SSE results are different from x87. What exactly is going on? Are floating point calculations deterministic or not?

Unfortunately, the answer is not a simple “yes” or “no” but a resoundingly limp “maybe?”

Y si, lo de Casimiro es correcto. Si un tipo de datos te falla, entonces la solución es cambiarlo. Si se supone que estas haciendo cálculos financieros inevitablemente usa un tipo de dato money/decimal o almacena como INTEGER los valores y aplica las formulas correctas para ese caso -y asegurate de usar exactamente el mismo tipo a lo largo de toda la cadena de computación, osea, si en FB usas NUMERIC que en Delphi tengas el equivalente!-.

----
Es divertido saber que los aspectos fundamentales de la programación son así de confiables

[Casimiro Notevi]

Empezado por mamcx

Muchas veces sí estoy de acuerdo contigo

[Casimiro Notevi]

Empezado por mlara

...

Es que me ocurrió lo mismo que a ti. Cientos de clientes (por no decir miles ), después de muchísimos años, sin problemas. Y un día un cliente tiene un problema extraño, no le "cuadraban" unos datos que a todo el mundo le funcionaba bien. Siguiendo paso a paso nos encontramos con que la comparación con valores double no se hacía correctamente en según qué circunstancias. La solución es sencillamente cambiar double por numeric.
En nuestro caso fue fácil porque siempre he usado dominios para declarar los campos de las tablas, así que solamente se tuvo que cambiar la declaración de algunos dominios y no hubo que tocar los campos.

[[egostar]]

Empezado por mlara

Antes de continuar, quiero recordar que la exposición del tema se debe a que, al ejecutar la consulta de este post en "mil computadores" ... obtengo un 1 como resultado, menos en uno de ellos. Qué sucede en ese equipo?

Me pregunto si el microprocesador es la diferencia, es decir AMD vs INTEL.

Digo a este punto cualquier cuestión es válida.

Saludos