dato real no exacto
 

Hola Foro,

Se me presenta el siguiente problema.

Lo primero decir que utilizo firebird 1.5 y 2.0

Tengo una tabla de prueba sencilla, con un campo codigo de tipo integer, llave primaria, y un campo Monto de tipo double precision.

Con el SQL Explorer hago lo siguiente.
En la data de la tabla pongo 1 para codigo y -5131.57 para Monto.
Luego Ejecuto las siguientes sentencias SQL

Código SQL [-]
UPDATE PRUEBA SET MONTO = MONTO + 5000.0000 WHERE CODIGO =1;
UPDATE PRUEBA SET MONTO = MONTO + 10.0500 WHERE CODIGO =1;
UPDATE PRUEBA SET MONTO = MONTO + 64.0000 WHERE CODIGO =1;
UPDATE PRUEBA SET MONTO = MONTO + 57.5200 WHERE CODIGO =1;

Y contrariamente a lo esperado el campo Monto no tiene el valor 0, si no 2.91322521661641E-13
He hecho otras pruebas con Numeric, me da el mismo resultado, y con float, fue peor porque el monto tenía un valor final de: 0.000178833011887036.

Estas pruebas las he hecho desde el SQL Explorer y desde el IBExpert.

Incluso utilizando el IBExpert para meter el primer registro, digito -5131.57, y si luego vuelvo a ese mismo campo no tiene ese valor, sino -5131.5699999999997, de todas maneras si hago un solo update por todo el monto -5131.57, si me deja el valor final en 0.

Alquien tiene idea de por qué puede pasar esto?

Muchas gracias por la ayuda.

Se trata de un error por redondeo. Se debe a que no todos los números reales (R) pueden representarse en forma binaria. Por ejemplo, es muy difícil representar el número 0'1, ya que no existe un valor (n) para el que (1/(2^n)) sea 1/10 (no existe ninguna potencia de 2 que sea igual a 10). En tu ejemplo, estoy por asegurar (aunque no lo he comprobado) que no es posible representar el número 10'05 en forma binaria.

Para evitar estos errores hay que elegir bien el tipo de dato. Primero, utiliza enteros siempre que sea posible. Si no hay más remedio que utilizar números reales o fraccionarios, debes utilizar el tipo más grande que puedas. Otra posbilidad es el BCD (Binario Codificado Decimal) que es más exacto que el punto flotante pero todavía más limitado ya que con 8 bit sólo puede representar 100 valores (00..99) y no 256, que sería lo normal (si no recuerdo mal, los tipos "CURRENCY" suelen utilizar BCD).

Una buena práctica para evitar errores de redondeo consiste en hacer las multiplicaciones primero y las divisiones al final (a menos que el riesgo de desbordamiento sea frecuente).

Gracias por la respuesta.
En mi caso si necesito que sea de tipo real, porque son cantidades monetarias en dos denominaciones diferentes, una cantidad sale a partir de la otra dividida por el tipo de cambio.
Voy a seguir revisando.