VALORES FANTASMAS FIREBIRD 2.1 valores Grandes

[Casimiro Notevi]

Hay otros hilos muy interesantes que se refieren concretamente a esos tipos de datos en firebird, pero no los encuentro...

[[Al González]]

Hola ASAPLTDA. En lo personal creí que tomarías de buena gana los comentarios que tuvimos para tu primer mensaje. Te ofrezco una disculpa si te hice sentir mal, pensé que lo tomarías como algo divertido, gozando del momento chusco que se suscitó, tras recapacitar y darte cuenta de lo precipitado que había sido el mensaje inicial del hilo. Siento que hayas tomado de forma negativa estas libertades propias del compañerismo...

Aceptar que una variable o campo de punto flotante (Float, Double, Single, Real, Extended, Real48,...) no siempre guarda el valor exacto que se le da es algo por lo que pasa tarde o temprano casi todo programador.

Una variable o campo entero tiene dos límites: el valor máximo y el valor mínimo. Puede contener un número entero siempre que ese número se encuentre en el rango que enmarcan dichos límites. Entre más bits tenga la variable o campo para almacenar el valor, mayor será ese rango. Con 32 bits, por ejemplo, la variable puede tener uno de 4294967296 valores posibles.

Una variable o campo de punto o coma flotante es otra cosa. Teóricamente puede almacenar cualquier número real, es decir, tanto números enteros (0, -400, 87, 23000), como decimales (0.5, -400.8, 87.6, 23000.9) y con cualquier cantidad de cifras (0.5, -400.8001, 87.783992338, 23000.752). Esto hace que los límites de un flotante no sean simplemente el valor menor y el valor mayor, como en el caso de los enteros, sino la "precisión" o exactitud con que puede guardar un número. Es un hecho que entre más grande sea la variable (Single, Double, Extended) más bits tiene para mejorar esa precisión o exactitud.

¿Cuántos bits necesita tener una variable para poder guardar cualquier número real? Si quieres responder esa pregunta, tendrás que preguntarte primero cuántos números reales existen. ¡Son infinitos! Y por ello ni una variable que ocupara toda la memoria RAM podría guardar a cualquiera de ellos con precisión.

Ante esto, el estándar que adoptaron los fabricantes de hardware y software hace muchos años fue el de permitir que las variables y campos de tipo flotante sacrifiquen la exactitud de los números que almacenan, a fin de que en la práctica podamos usar estas variables y campos para manejar "cualquier" valor que deseemos, aunque haya de repente una pequeña pérdida o ganancia de decimales. Después de todo, para la gran mayoría de las aplicaciones sólo interesan unas cuantas decimales (generalmente de 2 a 5). Y si son números reales muy grandes sin parte decimal, al no poder ser representados por los bits que tienen estas variables, se sacrifica también una parte de los mismos (por ello la diferencia que viste).

Es la naturaleza de los valores de punto / coma flotante. Están diseñados para guardar "cualquier valor", pero esa capacidad tiene un costo, el costo de la precisión, así que en realidad no guardan valores específicos, sino aproximaciones. Internamente, sus bits no representan un sólo dato, como las variables de tipo entero, sino varios datos que son factores de una fórmula. La computadora ejecuta tal fórmula con dichos datos para poder hacer algo con el número. Esto es a grandes rasgos, sin entrar en detalles demasiados técnicos (en parte por falta de conocimiento mía).

Si quieres un campo que guarde el valor que tú le des y no una aproximación, no uses campos de tipo flotante como Float o Double. Usa Integer si son enteros o Numeric si han de llevar una parte decimal.

Un abrazo flotante.

Al.

P.D. Esta fue una de mis pésimas explicaciones, pero quizá haya valido la pena.

[[Delphius]]

Hay un artículo extenso , en inglés, que lleva un nombre bien calzado: "Lo que todo informático debe saber sobre aritmética de punto flotante".
Si leyeras ese artículo sabrías el porque de este misterio. Cuando uno va a trabajar con punto flotante debe estar consciente de que se trabaja con cierta precisión y no con exactitud.

Por cierto, cuando uno trabaja con el tipo NUMERIC(x,y) en realidad está utilizando una aritmética de punto fijo. Y en términos prácticos Firebird internamente aprovecha los tipos enteros que ofrecen aritmética exacta (siempre y cuando los valores estén en su rango, obviamente) por lo que no hay pérdida alguna. Ahora bien, en aritmética de punto fijo se establece la cantidad de decimales esperados... si los valores con los que se va a trabajar son demasiados grandes o no tienen una cantidad fija o esperada no queda otra que utilizar el tipo double que ofrece una "exactitud" hasta los 15 dígitos.

Saludos,

[ASAPLTDA]

Independiente de que algunas lineas hallan exaltado los animos , solo los escrito reflejan el esfuerzo de una comunidad en apoyar a uno de sus integrantes.
agradesco su cooperacion y me disculpo con todos los foristas cuando un comentario mio los incomodo.
Gracias foristas por su exfuerzo dedicacion y paciencia

[Casimiro Notevi]

Empezado por ASAPLTDA

Gracias foristas por su exfuerzo dedicacion y paciencia

Gracias a ti, amigo