13 respuestas en este tema

[felipe]

Que tal a todos,
tengo un curioso error con mi base de datos en firebird, pues ultimamente me esta guardando algunos valores como no debe ser.

El caso específico es el siguiente, tengo en una tabla un campo tipo float sobre el cual guardo valores numéricos enteros, pero que en algunos casos exceden de 10 caracteres. Si por ejemplo escribo el valor 1112789123 este me lo cambia por 1112789184, esto es comprobado desde el propio IB Expert.

La verdad no entiendo que pueda estar pasando o una causa lógica para explicarlo, este campo es único en la base de datos, no se repite, no tiene ninguna relación y tampoco tiene valores decimales como para pensar en un redondeo (que ni siquiera tiene sentido viendo la diferencia de los valores).

¿Alguna idea... sugerencia?


Saludos!

[egostar]

¿Como tienes configurado el campo?

Decimal, Numeric, ......

Yo suelo usar siempre Numeric(15.x) y nunca he tenido problemas de ese tipo.

Salud OS

[felipe]

¿Como tienes configurado el campo?

Decimal, Numeric, ......

Yo suelo usar siempre Numeric(15.x) y nunca he tenido problemas de ese tipo.

Salud OS

Tipo float amigo... la cosa es que antes no había tenido este tipo de problemas, ¿como usas el numeric exactamente?


Saludos!

[Faust]

Una vez a algunos de mis jefes se le ocurrió usar float para cálculos monetarios, hasta que empecé a encontrar bugs...  .

Mejor usa el Numeric que aconseja Egostar.

Saludos y buen inicio de semana.

[felipe]

Una vez a algunos de mis jefes se le ocurrió usar float para cálculos monetarios, hasta que empecé a encontrar bugs...  .

Mejor usa el Numeric que aconseja Egostar.

Saludos y buen inicio de semana.

Para cálculos numéricos es un completo caos, eso si lo sabía... pero como este número no era para eso pensé que no daría problema.

Con lo que me dicen al parecer entonces la única solución será cambiar el tipo.
¿Última palabra?


Saludos!

[egostar]

Con lo que me dicen al parecer entonces la única solución será cambiar el tipo.
¿Última palabra?

Saludos!

La última palabra la tiene usted mi amigo Yo opino que lo cambie.

Salud OS

[felipe]

Con lo que me dicen al parecer entonces la única solución será cambiar el tipo.
¿Última palabra?

Saludos!

La última palabra la tiene usted mi amigo Yo opino que lo cambie.

Salud OS

Pues no será una muy agradable tarea, pero si esto ayuda con el problema es preferible.
Les comentaré como funciona.


Saludos!

[egostar]

Usted dele sin miedo, mas se perdio en la guerra

Salud OS

[Delphius]

Puedo preguntar una cosita porque no me queda muy claro el asunto:

¿Porqué se está utilizando un campo FLOAT para guardar números enteros?

Si es correcto lo que dices:

El caso específico es el siguiente, tengo en una tabla un campo tipo float sobre el cual guardo valores numéricos enteros

Si es entero entonces no necesita decimales, ergo el tipo no es lo más adecuado habiendo especialmente el tipo para ello: INTEGER y BIGINT.
O en todo caso, emplear NUMERIC(XX,0) o DECIMAL(XX,0)

Lo que dices sobre el tipo FLOAT para operaciones ariteméticas de tipo monetarias es cierto. Es mejor emplear el tipo NUMERIC(XX,2) ya que este es convertido y perfectamente adaptable el tipo Currency de Delphi que está especialmente diseñado para estos casos.
El motivo es que FLOAT es un tipo de dato que se basa en el formato de coma flotante y los números almacenados no necesariamente van a ser 100% exactos y precisos del que se desea. FLOAT almacena un valor aproximado a éste.
Y todas las operaciones en la que se vea afectado tienen cierta pérdida de precisión.

FLOAT y DOBLE PRECISION se deben emplear en casos en los que se permite cierta perdida de precisión... se estila mucho en operaciones del tipo científicas y/p enfocadas a cálculos de nivel de ingeniería.

Si se busca precisión a una cantidad FIJAS de decimales, es momento de pensar en NUMERIC o DECIMAL.

Bueno, me despido... comienza el partido de Argentina... vuelvo al rato

Saludos,

[felipe]

Usted dele sin miedo, mas se perdio en la guerra

Salud OS

Jeje... ya lo creo
El caso es que probé con numeric y hasta ahora todo bien... sin hembargo me queda la duda del porqué dicho comportamiento con los float en un valor de cero decimales...

Gracias Delphius por el comentario, usé float por cuestiones de tamaño, elegir este tipo y no un entero de grandes capacidades fué cosa de afán en el diseño, pues al ser un campo sin mayor actividad descarté que pudiera dar problema... pero ya ves, no fué así.

Saludos!

[Faust]

Usted dele sin miedo, mas se perdio en la guerra

Salud OS

Jeje... ya lo creo
El caso es que probé con numeric y hasta ahora todo bien... sin hembargo me queda la duda del porqué dicho comportamiento con los float en un valor de cero decimales...

Saludos!

Pues es uno de los Misterios sin resolver, aunque le guardes p. ej. 5642 a un campo float, es seguro que no guarde el valor entero, sino un float poquititito menor o poquititito mayor, que a primera vista lo desprecias, pero a la larga si genera bugs difíciles de encontrar, en vez del 5642 podría guardar: 5641.9966542156 ó 54642.0011265487... nada preciso.

He dicho uno más de los misterios sin resolver

[Delphius]

Hola,

No hay ningún misterio.
Así trabaja el tipo FLOAT . Se sabe que no hay cosa más difícil para una PC que operar con números de coma flotante, y eso se debe a que se está OBLIGADO a perder precisión... le es imposible almacenar infinitos decimales (eso por empezar) y también influye la cantidad de memoria destinada para almacenar números.

El formato establecido por la IEEE 754 establece como ha de tratarse los floats.
La forma en como se almacenan los números es lo que condiciona la posibilidad de representarlos. NO TODOS LOS NÚMEROS SE PUEDEN REPRESENTAR y es por ello que se almacena un valor APROXIMADO.

El siguiente artículo lo explica mejor que yo.

El asunto es que cuando se trabaja con float y double precision no se espera una aritmética precisa. Y por lo general se establece un criterio de error permisible... En la teoría del Cálculo Numérico se habla del error relativo y absoluto para medirlo. Más o menos para hacerla corta... esta disciplina, entre algunas de sus funciones, es diseñar algoritmos que trabajen con cierto nivel de error. Todos, o casi todos, de sus cálculos están basados para que el valor obtenido esté en un rango (+- %error). Es decir algo como:
valor_min_aceptado <= valor_obtenido <= valor_max_aceptado

Los efectos acumulativos de las operaciones pueden ser grandes cuantas más operaciones existan.... Incluso: No es lo mismo sumar N veces que multiplicar por N, por ejemplo.

Un ejemplo sencillo: en términos algebraicos la operación a(b + c) es igual a ab + ac. En términos numéricos (y para una computadora) no es lo mismo... la primera opción tiene una mejor tasa de error que la segunda.

Hasta cierto punto, aplicando redondeos (por arriba y por debajo) puede ayudar a evitar esos dolores de cabeza que comentan, pero en última repito: si se busca operar con una cantidad ya establecida de decimales es mejor optar por un tipo de datos que esté mejor preparado y que no permita el efecto de pérdida de precisión.

Saludos,

[Faust]

El caso es que para efectos prácticos no sirve cuando se necesite precisión.

Gracias a Delphius por la explicación...

[Delphius]

El caso es que para efectos prácticos no sirve cuando se necesite precisión.

Gracias a Delphius por la explicación...

OJO... en realidad no es que no sirva y no posean precisión... sino que el término precisión está dado de otra forma.
Los float si son precisos, y esta precisión está dada por la cantidad de decimales (7 para float y 15/16 para el double... en arquitectura de 32bit). Cuanto más decimales.... más precisos son los valores (más cercanos al valor real).

Nota como he dicho: no se espera aritmética precisa a contraparte de una aritmética exacta.
Si se desea trabajar con números exactos hay tipos especiales para ello, pero esto no quita que los flotantes no sean precisos... son precisos a cierta cantidad de decimales.

Todo depende del uso que le demos... la practicidad de este tipo se da en el contexto en el que se aplique y en como.

Saludos,