Extraer parte entera de una division en sql firebird , falla

[[Delphius]]

Hola,

Lo veo "fuerte y claro"

Acabo de ver que tu prueba corre en un FB 1.5.5 ¿habrá cambiado algo entre 1.5.3 y 1.5.5 como para que hayan variado los resultados? ¿O será que IBExpert me lo redondeó solito? Voy a probar con una "conexión cruda" y directa con isql para sacarnos dudas.

Saludos,

[[Delphius]]

Pues creo que ya podríamos confirmarlo: es un tema de versiones, desde Firebird 1.5.5 se ha cambiado el modo de regresar resultados numéricos.

Hice una prueba directa, empleando FB 1.5.3 y obtuve 1 empleando 90/60. Si indico 90.0/60.0 allí si regresa 1,5.

Como lo ha indicado Casi, en 1.5.5 esto ha cambiado y regresa en coma flotante.

Muy posiblemente la regla a aplicar ya no reside en los operandos sino en el tipo del resultado.

Por seguridad si desea obtener el número truncado debe emplearse la función para ello. Como he comentado, SI existe desde FB 1.0 y se llama Truncate() pero necesita declararla. Desde FB 2.1 ya viene incorporada al motor y su nombre ha sido cambiado por Trunc().

Saludos,

[Casimiro Notevi]

Misterio desvelado. Seguramente está en las notas que publican sobre los cambios realizados

[[Al González]]

Esperen un momento.

Código SQL [-]
Select 90 / 60 From RDB$DataBase

Firebird 1.5.3 (Delphius, Al), resultado: 1
Firebird 1.5.5 (Casimiro), resultado: 1.5
Firebird 2.0 (Joe_Balda), resultado: 1.5 (por confirmar)
Firebird 2.5 (ecfisa), resultado: 1 (por confirmar)

¿Realmente será un asunto de versiones? ¿Algo que dejó de estar en la versión 1.5.5 reapareció en la versión 2.5?

[[Delphius]]

Ummm... me has dado que pensar Al.

Lo que si es bueno recalcar es que no es lo mismo hacer:

Código SQL [-]
90/60

que hacer

Código SQL [-]
Cast(90/60 as integer)

En el primer caso el resultado dependenderá de como esté implementado el algoritmo para generar e interpretar el tipo. Esto es lo que hemos demostrado que varía de versión a versión.

En el segundo caso, independientemente de la versión del motor, DEBERÍA regresar el entero redondeado. Y como ha mencionado Al, por defecto se aplica el redondeo al par más cercano o también conocido como método del banquero.

Ahora bien, si se quiere hacer más líos podríamos comprobar si resulta ser lo mismo a esto:

Código SQL [-]
Cast(90.0/60.0 as integer)

Es decir: probar 4 posibilidades: Con/Sin cast y Con/Sin .0. De este modo podríamos armar una tabla de 2 entradas y comparar resultados. ¿Les parece?

EDITO:
Por favor, a fin de evitar mayor confusión que la generada, no digan 2.5 ¡Digan hasta el apellido! mencionen la sub-versión menor. Tomensé la molestia de decir ese numerito que mucho importa; aunque no lo crean. Es decir: 2.5.algo

Saludos,

[[Delphius]]

Aquí presento los resultados tabulados para que se aprecie bien las diferencias. Espero que con esto quede más claro la cosa:

+----------+-------+-----------+
| FB 1.5.3 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |     1 |         2 |
+----------+-------+-----------+
| S/Cast() |     1 |      1,50 |
+----------+-------+-----------+

Las consultas fueron:

Código SQL [-]
select cast(90/60 as integer) as Nro from rdb$database
select cast(90.0/60.0 as integer) as Nro from rdb$database
select 90/60 as Nro from rdb$database
select 90.0/60.0 as Nro from rdb$database

Respectivamente.
Puede apreciarse que el motor de FB 1.5.3 prioriza y determina el resultado dependiendo del tipo de los operandos. Y como intuía, aplica redondeo cuando se utiliza Cast.

Apreciaría que los demás siguieran la misma prueba, con éstas consultas. Y por si hay que añadir más factores a considerar entonces sumemos el SO: en mi caso Windows XP sp2

Saludos,

[Casimiro Notevi]

+----------+-------+-----------+
| FB 1.5.3 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |     1 |         2 |
+----------+-------+-----------+
| S/Cast() |     1 |      1,50 |
+----------+-------+-----------+

+----------+-------+-----------+
| FB 1.5.5 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |     2 |         2 |
+----------+-------+-----------+
| S/Cast() |  1.50 |      1,50 |
+----------+-------+-----------+
+----------+-------+-----------+
| FB 2.1.1 | 90/60 | 90.0/60.0 |
+----------+-------+-----------+
| C/Cast() |     1 |         2 |
+----------+-------+-----------+
| S/Cast() |     1 |      1,50 |
+----------+-------+-----------+
 

Añado mis resultados

[[Al González]]

Empezado por Delphius

Y como ha mencionado Al, por defecto se aplica el redondeo al par más cercano o también conocido como método del banquero.

No Marcelo, el método de redondeo que utilizan los motores de bases de datos para resolver números que están "a la mitad", no es el "del banquero" (al par más cercano), sino hacia el infinito, es decir, hacia el valor absoluto superior (1.5 queda como 2; 2.5 queda como 3; -1.5 queda como -2; -2.5 queda como -3). Esto según lo visto en el enlace que puse mensajes más arriba. Cabe decir que todavía no he tenido la suerte de mirar esa norma en ningún documento, a pesar de que tiene toda la pinta de ser una regla formal (sería mucha coincidencia que todos esos fabricantes de bases de datos hubiesen optado por el mismo tipo de redondeo sin un consenso previo).

Ahora, respecto a los resultados que todos nosotros hemos presentado en los mensajes más recientes, queda claro que el molde de tipo "Cast As Integer" trabaja de la misma manera en todas las versiones de Firebird, manera que, por cierto, es la esperada: números a la mitad "suben" (redondeo hacia el infinito). En esto no hay sorpresas.

La ÚNICA diferencia en todo esto es, según se ve, la forma en que cada versión de Firebird maneja las divisiones entre números de tipo entero. Unas versiones truncan la parte fraccionaria y otras no. Por ello es que la sentencia que por ahora valdría la pena probar es solamente la de una simple división entre enteros:

Código SQL [-]
Select 3 / 2 From RDB$DataBase

Ya vimos que una sentencia como esa, trunca la parte fraccionaria del resultado (1.5 -> 1), excepto en un rango de versiones que va, tentativamente, de la 1.5.5 a la 2.0.

Lo que convendría dejar claro es que, aun con esa diferencia de comportamiento entre un rango de versiones y el resto, ninguna versión de Firebird falla en redondear consistentemente un 1 como 1 y un 1.5 como 2 al aplicarle un Cast As Integer. ¿Estamos de acuerdo?

Despejado el problema, queda por un lado recomendarle a Joe_Balda, quien usa una de las versiones del "rango rebelde" (Firebird 2.0):

a) actualizarse a una versión superior.

b) hacer un truncamiento de la parte fraccionaria del resultado de la división, ya sea con una UDF, usando Substring, etc.

Por otra parte, la investigación de por qué unas versiones de Firebird truncan las divisiones de enteros y otras no. Y lo que son las cosas, mientras escribía estas líneas tuve la suerte de encontrar este documento:

http://www.firebirdsql.org/manual/qs...ebird-sql.html

Firebird concuerda con el estándar SQL truncando el resultado (cociente) de un cálculo entero/entero hacia el siguiente entero más bajo. Esto puede tener resultados [que quizá le parezcan] raros a menos que usted esté consciente de ello [de esta regla del estándar SQL].

Por ejemplo, este cálculo es correcto en SQL:

1 / 3 = 0

La fuente del documento parece lo suficientemente oficial como para dar por sentado que:

Las versiones 1.5.5, 1.5.6 y 2.0 tienen un defecto (bug) con la división entre enteros.

Un abrazo acorde al estándar.

Al González.