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).