VALORES FANTASMAS FIREBIRD 2.1 valores Grandes

[ASAPLTDA]

Buenas Tardes Foristas
Se presento un incidente con la base de datos firebird 2.1 , lo comparto para que tengan cuidado con este error , el cual no genera mensaje de error cuando cambia el valor

Table
// SE GENERA EL ERROR CON VALORES GRANDES

Código SQL [-]
 CREATE TABLE PRUEBA (VALOR1 FLOAT);
UPDATE PRUEBA SET VALOR1= 374.031.472;
SELECT VALOR1 FROM PRUEBA = 374.031.478;

DEFINIR EL VALOR COMO DOUBLE PRECISION

Código SQL [-]
UPDATE PRUEBA SET VALOR1= 374.031.472;
SELECT VALOR1 FROM PRUEBA = 374.031.472;

[roman]

¿Y cuál es el error que se genera?

Por cierto, ¿firebird permite dos puntos en un valor flotante?

// Saludos

[Casimiro Notevi]

¡Huy!, me has dejado sordo con tanto grito

[Casimiro Notevi]

Me parece que el error es del que introduce los datos

[[Al González]]

Apuesto a que lo escribió desde una de esas modernas tabletas.

Ya, en serio, ASAPLTDA. ¿Podrías explicar el problema?

(De preferencia respirando y con un teclado normal).

[ASAPLTDA]

el problema es que se graba y firebird no envia ningun mensaje de error, solo recibe el valor y cuando se hace el commit cambia el valor . Por eso envio el comentario a la comunidad ya que los errores silenciosos son los peligrosos

Ahora el valor que reporto en el sistema es sin separador de miles, he colocado los separadores solo para facilitar la lectura

el problema se observo usando delphi 5 / ibexpert base de datos firebird 2.1


¡Huy!, me has dejado sordo con tanto grito , me disculpo con las persona sensibles al ruido. pero solo se dejo en mayusculas los mensajes de aviso
Ahora cuando te pasa algo como eso ya no grito, busco una solución o solicitud ayuda a travez de este foro

[Casimiro Notevi]

Hombre, para empezar (y no despistarnos) deberías de haber puesto las sentencias sql originales y no con "máscara"

Y lo segundo, y más importante, no es un error, así como lo lees

Eso te pasa por usar float para esos menesteres. Mejor incluso que double, usa numeric.

Haz una búsqueda por los foros, es un tema que se ha tratado en diversas ocasiones.


Por cierto, yo también pensaba que era un error que yo fuese tan feo, fui al médico por si era alguna deformidad debido a alguna extraña y desconocida enfermedad. El médico me contestó que no era ningún error, sino que yo era así por naturaleza, feo, feo, feo...
Y no por eso voy gritando por ahí ¡¡¡soy un error, soy un error...!!!

Moraleja: que no vayas gritando por ahí que firebird tiene un error muy grave, cuando eso no es un error, es lo normal.

[roman]

Hasta donde entiendo, esto no es un error y por eso Firebird no lo reporta. Tiene que ver con la precisión que se especifique para el número flotante.

// Saludos

[roman]

Je, je. Me ganó Casimiro por un pelín

// Saludos

[ASAPLTDA]

No se cual es alcance para considerar si algo que sucede es un error, y si lo expreso es porque cuando en la vida real uno se le presenta un problema de esos le puedo asegurar que es muy grave y esa es la razon de informar.



Por ejemplo : si en un campo float usas el valor 374031472 firebird recibe el valor pero almacena o retorna 374031478
valor 374000000 firebird recibe el valor pero almacena o retorna 374000000
valor 374031000 firebird recibe el valor pero almacena o retorna 374031008
valor 375000000 firebird recibe el valor pero almacena o retorna 375000000
13835485725 -> 13835486208

Como pueden observar si se ingresa un dato uno espera que se almacene el mismo valor, fuera del conocido problema del manejo de decimales y ya que no es muy frecuente usar cifras en el sistema que soporto.

Te todos modos agradesco sus comentarios , pero también hago un critica constructiva a todos las personas para que no traten a otros en una forma poco cordial ya que el experto existe por el menor grado de conocimiento de otros

[Casimiro Notevi]

Empezado por ASAPLTDA

Como pueden observar si se ingresa un dato uno espera que se almacene el mismo valor, fuera del conocido problema del manejo de decimales y ya que no es muy frecuente usar cifras en el sistema que soporto.

Te todos modos agradesco sus comentarios , pero también hago un critica constructiva a todos las personas para que no traten a otros en una forma poco cordial

Disculpa, amigo ASAPLTDA, pero no creo que se te haya tratado de forma poco cordial. Más bien ha sido al revés, tú has sido quien ha incumplido algunas normas de los foros, has llegado GRITANDO y culpando de un error a FB, error que no existe, era sólo desconocimiento tuyo sobre los tipos de datos, es lo mismo que si dices que un integer no almacena números de 20 cifras, pues claro que no, para eso no puedes usar un integer. Pues es exactamente el mismo caso.

Siento que te hayas molestado, pero todos nos equivocamos, mejor dicho, no podemos saberlo todo. El "problema" con los float los descubrí en 1998, y desde entonces usé siempre double. Sin embargo, estaba tan tranquilo cuando surgió un extraño incidente en ciertos cálculos (que ni recuerdo ahora mismo) y me tuvieron semanas dedicado a resolverlo, hace ahora 3 años, descubrí que (según qué casos) también podía traerme "problemas" los double, así que cambié a numeric(x,y). Y desde entonces se acabaron esos "problemas".
Que ya digo, no son problemas de los tipos, sino de no usar los correctos a cada caso.
Por ejemplo, para porcentajes puedes usar los float tranquilamente.

[ASAPLTDA]

Apreciado amigo, puedes gritar usando letras mayusculas y minusculas. El grito no esta en los caracteres si no en las expresiones usadas.

Pero reitero mi agradecimiento a todas las personas que respondieron haciendo un esfuerzo grande en buscar la solucion y mas aun en tomarse un tiempo para responder de una forma a otra aportando a la solucion de Mi problema y espero que esto contribuya a la solucion de otro que se enfrente a la misma situacion.

[Casimiro Notevi]

Mira este hilo, amigo ASAPLTDA, ahí se habla de todo esto, tipos, redondeos, casos reales, etc.
Te aconsejo que lo leas entero.

Y disculpa de nuevo si antes fui un poco "bruto" contestando.

[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