hgiacobone
07-12-2017, 15:57:20
Bueno, si aun no lo han sufrido estén atentos.
Transmito nuestra reciente experiencia.
Nosotros utilizamos XE-10.2 Tokyo v.25.0.263x pero aplica en cualquier XE compilado en 64 bits :(
Observen este ejemplo:
var
F: Single;
begin
F := 0.1;
if F = 0.1 then
ShowMessage('equal')
else
ShowMessage('not equal');
end;
La pregunta del millón es: ¿cuál será la respuesta de salida?
Respuesta: "not equal" :eek:
Aquí un muy buen artículo, totalmente recomendado, con la explicación del problema: http://rvelthuis.de/articles/articles-floats.html
Por ejemplo, a nosotros nos acaba de pasar con, nada menos, que la emisión de comprobantes de ventas y el cálculo de percepciones de ingresos brutos.
Algo sencillo:
function Parte_Entera(f: single): integer;
begin
Result:= int( f );
end
Si el valor de entrada es por ejemplo "2946" sin ningún decimal, la función anterior devolverá "2945" y, si se trata de dinero es un Euro menos y si se trata de enviar un rover a Marte con suerte lo aterrizamos en Urano :)
Aquí, http://docwiki.embarcadero.com/RADStudio/Tokyo/en/About_Floating-Point_Arithmetic la gente de Embarcadero te ilustra como ellos se "lavan las manos" y en síntesis te dicen que el problema puede ser tu diseño, por pensar que una variable Single o Double de valor "0,25" en realidad por ejemplo puede llegar a ser "0.2499999999999999999999" y que obviamente TODO el mundo lo sabe menos vos :mad:
qP:-)...empiezo a extrañar mucho al querido Clipper 5.01
Ahora bien, a modo de resumen, utilizando XE compilado en 64 bits, el tipo Double pasa a ser interpretada como Extended y no solo eso, todo el manejo de variables internamente XE lo hace convertido a Extended.
Por consiguiente, como lo recomendable es no ir cambiando entre tipos para que nos se "pierdan decimales" entre conversiones, lo recomendado es manejar todo en Extended, aun cuando necesites operar solo con 2 decimales :confused:
Sin embrago, en operaciones tradicionales de suma, resta y multiplicación, los resultados parecen mantenerse bien aun cuando sea entre tipos diferentes.
Las divisiones, exponenciales y otros cómputos como el uso de RoundTo() que puedan generar varios decimales ya presentan algún problema.
En el caso de REDONDEO, nuestra solución fue utilizar una función propia, basada en una antigua de Delphi 7 y "forzando" a utiliza el redondeo hacia arriba:
Function RoundD(x: Extended; d: Integer): Extended;
var
n, f: Extended;
i: integer;
OldRM: TRoundingMode;
begin
n := Power(10, d);
x := x * n;
{--“Bankers rounding”--->Result := ( (Int(x) + Int(Frac(x)*2) ) / n);}
OldRM := GetRoundMode;
try
SetRoundMode(rmUp);
i := Trunc(X);
f := ((x - i) + 0.00000001) ;
if f>=1
then Result := (x / n ) {cuando es un entero}
else Result := ( (Int(x) + Int((f*2)) ) / n );
finally
SetRoundMode(OldRM);
end;
end;
Suerte amigos!:D
Transmito nuestra reciente experiencia.
Nosotros utilizamos XE-10.2 Tokyo v.25.0.263x pero aplica en cualquier XE compilado en 64 bits :(
Observen este ejemplo:
var
F: Single;
begin
F := 0.1;
if F = 0.1 then
ShowMessage('equal')
else
ShowMessage('not equal');
end;
La pregunta del millón es: ¿cuál será la respuesta de salida?
Respuesta: "not equal" :eek:
Aquí un muy buen artículo, totalmente recomendado, con la explicación del problema: http://rvelthuis.de/articles/articles-floats.html
Por ejemplo, a nosotros nos acaba de pasar con, nada menos, que la emisión de comprobantes de ventas y el cálculo de percepciones de ingresos brutos.
Algo sencillo:
function Parte_Entera(f: single): integer;
begin
Result:= int( f );
end
Si el valor de entrada es por ejemplo "2946" sin ningún decimal, la función anterior devolverá "2945" y, si se trata de dinero es un Euro menos y si se trata de enviar un rover a Marte con suerte lo aterrizamos en Urano :)
Aquí, http://docwiki.embarcadero.com/RADStudio/Tokyo/en/About_Floating-Point_Arithmetic la gente de Embarcadero te ilustra como ellos se "lavan las manos" y en síntesis te dicen que el problema puede ser tu diseño, por pensar que una variable Single o Double de valor "0,25" en realidad por ejemplo puede llegar a ser "0.2499999999999999999999" y que obviamente TODO el mundo lo sabe menos vos :mad:
qP:-)...empiezo a extrañar mucho al querido Clipper 5.01
Ahora bien, a modo de resumen, utilizando XE compilado en 64 bits, el tipo Double pasa a ser interpretada como Extended y no solo eso, todo el manejo de variables internamente XE lo hace convertido a Extended.
Por consiguiente, como lo recomendable es no ir cambiando entre tipos para que nos se "pierdan decimales" entre conversiones, lo recomendado es manejar todo en Extended, aun cuando necesites operar solo con 2 decimales :confused:
Sin embrago, en operaciones tradicionales de suma, resta y multiplicación, los resultados parecen mantenerse bien aun cuando sea entre tipos diferentes.
Las divisiones, exponenciales y otros cómputos como el uso de RoundTo() que puedan generar varios decimales ya presentan algún problema.
En el caso de REDONDEO, nuestra solución fue utilizar una función propia, basada en una antigua de Delphi 7 y "forzando" a utiliza el redondeo hacia arriba:
Function RoundD(x: Extended; d: Integer): Extended;
var
n, f: Extended;
i: integer;
OldRM: TRoundingMode;
begin
n := Power(10, d);
x := x * n;
{--“Bankers rounding”--->Result := ( (Int(x) + Int(Frac(x)*2) ) / n);}
OldRM := GetRoundMode;
try
SetRoundMode(rmUp);
i := Trunc(X);
f := ((x - i) + 0.00000001) ;
if f>=1
then Result := (x / n ) {cuando es un entero}
else Result := ( (Int(x) + Int((f*2)) ) / n );
finally
SetRoundMode(OldRM);
end;
end;
Suerte amigos!:D