This is a multi-part message in MIME format.
------=_NextPart_000_0009_01CBBFB4.4E6EBDD0
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000A_01CBBFB4.4E6EBDD0"
------=_NextPart_001_000A_01CBBFB4.4E6EBDD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Me estoy volviendo loco con el c=E1lculo de n=FAmeros con decimales.
Calculemos mentalmente el siguiente c=F3digo:
NUMERO =3D 6.05
NUMERO - =3D 6
El resultado que uno piensa ser=EDa NUMERO =3D 0.05 =BFo no?, pues =
aunque parezca incre=EDble mi ordenador dice que no.
Si ahora a=F1ado el c=F3digo IF NUMERO > =3D 0.05
la condici=F3n no se cumple y uno se queda con cara de pasmado.
Probad este c=F3digo:
NUMERO =3D 6.05
NUMERO - =3D 6
IF NUMERO>=3D0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQU=CD PASA ALGO RARO")
ENDIF
Trasteando, trasteando, he puesto un ROUN() despu=E9s de la resta:
NUMERO =3D 6.05
NUMERO - =3D 6
NUMERO=3DROUND(NUMERO,2)
IF NUMERO>=3D0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQU=CD PASA ALGO RARO")
ENDIF
Y parece que ya funciona con "l=F3gica" y se ejecuta el primer MsgInfo
=BFEsto es un problema de Xailer, de Harbour, o de que yo tengo el d=EDa =
tonto?
Gracias anticipadas por vuestras opiniones.
Un saludo
Paco Mart=EDnez
------=_NextPart_001_000A_01CBBFB4.4E6EBDD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18999">
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT size=3D2 face=3DArial>Me estoy volviendo loco con el =
c=E1lculo de n=FAmeros=20
con decimales.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>Calculemos mentalmente el siguiente=20
c=F3digo:</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>ÂÂÂ ÂÂÂ =
NUMERO =3D=20
6.05<BR>ÂÂÂ ÂÂÂ NUMERO - =3D =
6</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>El resultado que uno piensa ser=EDa =
NUMERO =3D=20
0.05Â =BFo no?, pues aunque parezca incre=EDble mi ordenador =
diceÂque=20
no.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>Si ahora a=F1ado el c=F3digo IF NUMERO =
> =3D=20
0.05</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>la condici=F3n =
<STRONG><U>no</U></STRONG> se cumple y=20
uno se queda con cara de pasmado.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>Probad este c=F3digo:</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>ÂÂ NUMERO =3D =
6.05<BR>ÂÂ NUMERO -=20
=3D 6<BR>ÂÂ IF =
NUMERO>=3D0.05<BR>ÂÂÂÂÂ=20
MsgInfo(NUMERO)<BR>ÂÂ ELSE<BR>ÂÂÂÂÂ=20
MsgInfo("AQU=CD PASA ALGO RARO")<BR>ÂÂ ENDIF</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>Trasteando, trasteando, he puesto un =
ROUN() despu=E9s=20
de la resta:</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>
<DIV><FONT size=3D2 face=3DArial></FONT>Â</DIV>
<DIV><FONT size=3D2 face=3DArial>ÂÂ NUMERO =3D =
6.05<BR>ÂÂ NUMERO -=20
=3D 6</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial>ÂÂÂ<FONT=20
color=3D#ff0000><STRONG>NUMERO=3DROUND(NUMERO,2)</STRONG> </FONT><BR> =
;Â IF=20
NUMERO>=3D0.05<BR>ÂÂÂÂÂ=20
MsgInfo(NUMERO)<BR>ÂÂ ELSE<BR>ÂÂÂÂÂ=20
MsgInfo("AQU=CD PASA ALGO RARO")<BR>ÂÂ ENDIF</FONT></DIV>
<DIV>Â</DIV>
<DIV>Y parece que ya funciona con "l=F3gica" y se ejecuta el primer =
MsgInfo</DIV>
<DIV>Â</DIV>
<DIV>=BFEsto es un problema de Xailer, de Harbour, o de que yo tengo el =
d=EDa=20
tonto?</DIV>
<DIV>Â</DIV>
<DIV>Gracias anticipadas por vuestras opiniones.</DIV>
<DIV>Un saludo</DIV>
<DIV>Paco Mart=EDnez</DIV></FONT></DIV></BODY></HTML>
------=_NextPart_001_000A_01CBBFB4.4E6EBDD0--
------=_NextPart_000_0009_01CBBFB4.4E6EBDD0
Content-Type: application/octet-stream;
name="DECIMALES.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="DECIMALES.zip"
UEsDBBQAAgAIAOtmPT4ITM3O/wAAAIYBAAAUAAAAU291cmNlL0RFQ0lNQUxF Uy5wcmdlkEtqwzAQ
hvcG32FQN0mgfgQaqMAFUdvB4EcqN9CtkEUtELZRpUUP2dPkArWVtAntLAbm +/95MOHG92ADBz1+
Cm5GDGn2XFSkzFrHc8l7oW9xMOl3J6Xig2s5cXkaMFSnzqoROgFiMJp1DBio OU1KcrZYXAuxZtT4
PFjwnmHYPoZRHG6jOF5o6Hu+dycHruw8Cb0xqYQOeI8WPp/IRWe1gIrJYbVe GACQye0wchwwf5VG
CcAJoN970T8Xtdfu+lhltEl2QfRwU98nO1cV+QU8JdGPY46q3Rd13qzO2trh rGyzvzoiL8cvOJCW
ACn3DVBCG3Sx12mR+x4Vxur5N99QSwMEFAACAAgA4WQ9PoQD2UhmAgAA6AQA AA0AAABERUNJTUFM
RVMueHBqXZPNkpswDMfvzPAOe+80s5D9PHBgSdLSCSFDMm2naQ7GKMRdbFxj dpOH3HeqHJwEekL6
/SVZks1mmaXfptF66zrro4QADuA6E2ioYlKzWgSTaRQn4Xy6cp201bLVVzI6 BUc1l6wCFRy+EpXX
rXKdhDCR1EVbQYBOW2kmK4hFo4mg0ASj9ch1fi4TItgOGt35McXDXGdJFOGg QTXopNMkGM1Q/I6+
acYb3bpOBhWQBgI0X1pWFcYwTRBxDGZZuIjiVZTeJGG2/lhMf918CbPoIzQh 8pixcq+x8FqRAhKi
Xs0pmMtBaGNu0uU6Thcr3EbY6poTzWgC/I2oCdAKWzut5NTSBPK2jMWu7txV K6WCppkzAYuW56CM
pngv4xyy2tdK01ZrJspO+UGUEOjN4Q2qwMOd1QrS0/5NV8Z7iSIExiFyhuvu EiMMqCvAXVtgQrGF
1y52M4kzvNs0i6dmpBVeDoUJU0Fn4dIFrdrihKxp1ttc4s42XkX+xwD8YNlZ PD8V9HpvQaoSlXn8
koX2OC/4tDkQ8zS23WdUsdx1/Cuu6aFj4+DzmTV/K6ahw3dXjD4/otYJ96bG vntuW6UtfejTN97B
R1PjDEv9zkTHn/rBpRatLfLc5xURZYe92z7nhKraCt6gl6Kw2O/jIt8JbWf1 xv2OUKHFWbn7L2cn
tVXu+zkNO1xzBkPvc9SsMBgc+yJFY5WnvkIojH0rDGan+KgkKe1V+LdDjfPa LtIfLEBKSwfzS6pA
1vZ8f4xSTulWNsXr77rI6bkB/66v8Ibx8iLdW4m+X9CDRYxL/KMu+NFivGr8 Ge0G/wFQSwECFAAU
AAIACADrZj0+CEzNzv8AAACGAQAAFAAAAAAAAAAAACAAtIEAAAAAU291cmNl L0RFQ0lNQUxFUy5w
cmdQSwECFAAUAAIACADhZD0+hAPZSGYCAADoBAAADQAAAAAAAAAAACAAtIEx AQAAREVDSU1BTEVT
LnhwalBLBQYAAAAAAgACAH0AAADCAwAAAAA=
------=_NextPart_000_0009_01CBBFB4.4E6EBDD0--
Attached files DECIMALES.zip (1.1 KB)Â
In order for this site to work correctly we need to store a small file (called a cookie) on your computer. Most every site in the world does this, however since the 25th of May 2011, by law we have to get your permission first. Please abandon the forum if you disagree.
Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.
Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.
DECIMALES... Algo raro
-
Carlos Ortiz
- Mensajes: 873
- Registrado: Mié Jul 01, 2009 5:44 pm
- Ubicación: Argentina - Córdoba
- Contactar:
DECIMALES... Algo raro
Opino que es de Harbour
"Francisco Martínez García" <pacoelche@hotmail.com> escribió en el mensaje news:4d440106$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Me estoy volviendo loco con el cálculo de números con decimales.
Calculemos mentalmente el siguiente código:
NUMERO = 6.05
NUMERO - = 6
El resultado que uno piensa sería NUMERO = 0.05 ¿o no?, pues aunque parezca increíble mi ordenador dice que no.
Si ahora añado el código IF NUMERO > = 0.05
la condición no se cumple y uno se queda con cara de pasmado.
Probad este código:
NUMERO = 6.05
NUMERO - = 6
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Trasteando, trasteando, he puesto un ROUN() después de la resta:
NUMERO = 6.05
NUMERO - = 6
NUMERO=ROUND(NUMERO,2)
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Y parece que ya funciona con "lógica" y se ejecuta el primer MsgInfo
¿Esto es un problema de Xailer, de Harbour, o de que yo tengo el día tonto?
Gracias anticipadas por vuestras opiniones.
Un saludo
Paco Martínez
--
"Francisco Martínez García" <pacoelche@hotmail.com> escribió en el mensaje news:4d440106$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Me estoy volviendo loco con el cálculo de números con decimales.
Calculemos mentalmente el siguiente código:
NUMERO = 6.05
NUMERO - = 6
El resultado que uno piensa sería NUMERO = 0.05 ¿o no?, pues aunque parezca increíble mi ordenador dice que no.
Si ahora añado el código IF NUMERO > = 0.05
la condición no se cumple y uno se queda con cara de pasmado.
Probad este código:
NUMERO = 6.05
NUMERO - = 6
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Trasteando, trasteando, he puesto un ROUN() después de la resta:
NUMERO = 6.05
NUMERO - = 6
NUMERO=ROUND(NUMERO,2)
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Y parece que ya funciona con "lógica" y se ejecuta el primer MsgInfo
¿Esto es un problema de Xailer, de Harbour, o de que yo tengo el día tonto?
Gracias anticipadas por vuestras opiniones.
Un saludo
Paco Martínez
--
@dbfarma
www.dbfarma.com.ar
www.dbfarma.com.ar
-
jasm.quitaesto
- Mensajes: 420
- Registrado: Sab Ago 16, 2008 9:06 pm
DECIMALES... Algo raro
¿Que valor tiene SET DECIMALS TO?
¿Y SET EXACT TO?
El 29/01/2011 12:59, Francisco Martínez García escribió:
> Me estoy volviendo loco con el cálculo de números con decimales.
> Calculemos mentalmente el siguiente código:
> NUMERO = 6.05
> NUMERO - = 6
> El resultado que uno piensa sería NUMERO = 0.05 ¿o no?, pues aunque
> parezca increíble mi ordenador dice que no.
> Si ahora añado el código IF NUMERO > = 0.05
> la condición *_no_* se cumple y uno se queda con cara de pasmado.
> Probad este código:
> NUMERO = 6.05
> NUMERO - = 6
> IF NUMERO>=0.05
> MsgInfo(NUMERO)
> ELSE
> MsgInfo("AQUí PASA ALGO RARO")
> ENDIF
> Trasteando, trasteando, he puesto un ROUN() después de la resta:
> NUMERO = 6.05
> NUMERO - = 6
> *NUMERO=ROUND(NUMERO,2)*
> IF NUMERO>=0.05
> MsgInfo(NUMERO)
> ELSE
> MsgInfo("AQUí PASA ALGO RARO")
> ENDIF
> Y parece que ya funciona con "lógica" y se ejecuta el primer MsgInfo
> ¿Esto es un problema de Xailer, de Harbour, o de que yo tengo el día tonto?
> Gracias anticipadas por vuestras opiniones.
> Un saludo
> Paco Martínez
¿Y SET EXACT TO?
El 29/01/2011 12:59, Francisco Martínez García escribió:
> Me estoy volviendo loco con el cálculo de números con decimales.
> Calculemos mentalmente el siguiente código:
> NUMERO = 6.05
> NUMERO - = 6
> El resultado que uno piensa sería NUMERO = 0.05 ¿o no?, pues aunque
> parezca increíble mi ordenador dice que no.
> Si ahora añado el código IF NUMERO > = 0.05
> la condición *_no_* se cumple y uno se queda con cara de pasmado.
> Probad este código:
> NUMERO = 6.05
> NUMERO - = 6
> IF NUMERO>=0.05
> MsgInfo(NUMERO)
> ELSE
> MsgInfo("AQUí PASA ALGO RARO")
> ENDIF
> Trasteando, trasteando, he puesto un ROUN() después de la resta:
> NUMERO = 6.05
> NUMERO - = 6
> *NUMERO=ROUND(NUMERO,2)*
> IF NUMERO>=0.05
> MsgInfo(NUMERO)
> ELSE
> MsgInfo("AQUí PASA ALGO RARO")
> ENDIF
> Y parece que ya funciona con "lógica" y se ejecuta el primer MsgInfo
> ¿Esto es un problema de Xailer, de Harbour, o de que yo tengo el día tonto?
> Gracias anticipadas por vuestras opiniones.
> Un saludo
> Paco Martínez
-
Bingen Ugaldebere
- Mensajes: 1310
- Registrado: Mié Sep 26, 2007 7:12 pm
DECIMALES... Algo raro
Si, es un problema de Harbour a nosotros también nos sucedió algo
parecido en un programa cuando nos decía que 0 era distinto de 0.00
para volverse loco.
Soluciones:
Multiplicar ambas cantidades por 100 y redondear el resultado
If !(Round(nDebe*100,0)=Round(nHaber*100,0))
MsgAlert("Hay un descuadre de "+Alltrim(Transform( (nDebe -
nHaber) , "@E 999,999,999.99")),"¡¡¡ Atención !!!")
lOk := .f.
EndIf
Hacer un CRC a ambas cantidades usando esta función de nuestra librería
Bisoft.Lib
**/
* FUNCION que Devuelve .T. si 2 cadenas. numeros, fechas, etc son
iguales por su CRC
* @author Bingen Ugaldebere
* @param xText1 Primera cadena, numero, fecha, etc...
* @param xText2 Segunda cadena, numero, fecha, etc...
* @return .T. o .F.
*/
Function CompareCharCRC(xText1, xText2)
Local nItem:=0, nCrc1:=0, nCrc2:=0
Local cText1:=Alltrim(Tostring(xText1))
Local cText2:=Alltrim(Tostring(xText2))
For nItem:=1 to Len(cText1)
nCrc1+=nItem*Asc(SubStr(cText1,nitem,1))
Next
For nItem:=1 to Len(cText2)
nCrc2+=nItem*Asc(SubStr(cText2,nitem,1))
Next
Return nCrc1==nCrc2
Salu2
parecido en un programa cuando nos decía que 0 era distinto de 0.00
para volverse loco.
Soluciones:
Multiplicar ambas cantidades por 100 y redondear el resultado
If !(Round(nDebe*100,0)=Round(nHaber*100,0))
MsgAlert("Hay un descuadre de "+Alltrim(Transform( (nDebe -
nHaber) , "@E 999,999,999.99")),"¡¡¡ Atención !!!")
lOk := .f.
EndIf
Hacer un CRC a ambas cantidades usando esta función de nuestra librería
Bisoft.Lib
**/
* FUNCION que Devuelve .T. si 2 cadenas. numeros, fechas, etc son
iguales por su CRC
* @author Bingen Ugaldebere
* @param xText1 Primera cadena, numero, fecha, etc...
* @param xText2 Segunda cadena, numero, fecha, etc...
* @return .T. o .F.
*/
Function CompareCharCRC(xText1, xText2)
Local nItem:=0, nCrc1:=0, nCrc2:=0
Local cText1:=Alltrim(Tostring(xText1))
Local cText2:=Alltrim(Tostring(xText2))
For nItem:=1 to Len(cText1)
nCrc1+=nItem*Asc(SubStr(cText1,nitem,1))
Next
For nItem:=1 to Len(cText2)
nCrc2+=nItem*Asc(SubStr(cText2,nitem,1))
Next
Return nCrc1==nCrc2
Salu2
DECIMALES... Algo raro
Hola,
Yo sugiero:
ErrSumClip(n1) == ErrSumClip(n2)
FUNCTION ErrSumClip(n); RETURN Val(Str(n, 14, 4))
Saludos
Francisco Martínez García escribió en mensaje <4d440106$[email=1@svctag-j7w3v3j.]1@svctag-j7w3v3j.[/email]>...
Me estoy volviendo loco con el cálculo de números con decimales.
Calculemos mentalmente el siguiente código:
NUMERO = 6.05
NUMERO - = 6
El resultado que uno piensa sería NUMERO = 0.05 ¿o no?, pues aunque parezca increíble mi ordenador dice que no.
Si ahora añado el código IF NUMERO > = 0.05
la condición no se cumple y uno se queda con cara de pasmado.
Probad este código:
NUMERO = 6.05
NUMERO - = 6
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Trasteando, trasteando, he puesto un ROUN() después de la resta:
NUMERO = 6.05
NUMERO - = 6
NUMERO=ROUND(NUMERO,2)
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Y parece que ya funciona con "lógica" y se ejecuta el primer MsgInfo
¿Esto es un problema de Xailer, de Harbour, o de que yo tengo el día tonto?
Gracias anticipadas por vuestras opiniones.
Un saludo
Paco Martínez
--
Yo sugiero:
ErrSumClip(n1) == ErrSumClip(n2)
FUNCTION ErrSumClip(n); RETURN Val(Str(n, 14, 4))
Saludos
Francisco Martínez García escribió en mensaje <4d440106$[email=1@svctag-j7w3v3j.]1@svctag-j7w3v3j.[/email]>...
Me estoy volviendo loco con el cálculo de números con decimales.
Calculemos mentalmente el siguiente código:
NUMERO = 6.05
NUMERO - = 6
El resultado que uno piensa sería NUMERO = 0.05 ¿o no?, pues aunque parezca increíble mi ordenador dice que no.
Si ahora añado el código IF NUMERO > = 0.05
la condición no se cumple y uno se queda con cara de pasmado.
Probad este código:
NUMERO = 6.05
NUMERO - = 6
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Trasteando, trasteando, he puesto un ROUN() después de la resta:
NUMERO = 6.05
NUMERO - = 6
NUMERO=ROUND(NUMERO,2)
IF NUMERO>=0.05
MsgInfo(NUMERO)
ELSE
MsgInfo("AQUí PASA ALGO RARO")
ENDIF
Y parece que ya funciona con "lógica" y se ejecuta el primer MsgInfo
¿Esto es un problema de Xailer, de Harbour, o de que yo tengo el día tonto?
Gracias anticipadas por vuestras opiniones.
Un saludo
Paco Martínez
--
DECIMALES... Algo raro
Paco y todos,
el problema no es Xailer, ni xHarbour, ni BCC. El problema está en la forma de manejar internamente los números decimales por parte del coprocesador matemático.
La familia x86 de Intel y AMD (y supongo que todos los demás micros actuales) siguen la norma IEEE-754, lo que significa que los números se guardan internamente en formato binario. Pero la conversión de números reales de decimal a binario no siempre es exacta. A veces hay pequeñas diferencias, y estas diferencias se ven incrementadas al realizar operaciones. Aquí teneis una explicación: http://en.wikipedia.org/wiki/Floating_p ... cy_problem s. Me temo que está en inglés porque no lo he encontrado en español, pero podeis traducirlo con google y se entiende bastante bien.
La mejor solución (aunque sé que es un coñazo de cuidado) es utilizar Round() en las comparaciones. P.ej.:
IF Round( x, 2 ) > Round( 0.05, 2 )
Afortunadamente, esto no hay que hacerlo siempre. La inmensa mayoría de las veces no es necesario, aunque sí habrá que hacerlo cuando el resultado sea crítico.
Y por cierto, para aquellos que utiliceis algún motor SQL, sabed que existe el mismo problema. Yo mismo lo he visto, cuando p.ej. en un asiento contable que está perfectamente cuadrado, sum(debe) - sum(haber) no daba 0. En ese caso, tuve que cambiarlo por round(sum(debe),2) - round(sum(haber),2)
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
--
el problema no es Xailer, ni xHarbour, ni BCC. El problema está en la forma de manejar internamente los números decimales por parte del coprocesador matemático.
La familia x86 de Intel y AMD (y supongo que todos los demás micros actuales) siguen la norma IEEE-754, lo que significa que los números se guardan internamente en formato binario. Pero la conversión de números reales de decimal a binario no siempre es exacta. A veces hay pequeñas diferencias, y estas diferencias se ven incrementadas al realizar operaciones. Aquí teneis una explicación: http://en.wikipedia.org/wiki/Floating_p ... cy_problem s. Me temo que está en inglés porque no lo he encontrado en español, pero podeis traducirlo con google y se entiende bastante bien.
La mejor solución (aunque sé que es un coñazo de cuidado) es utilizar Round() en las comparaciones. P.ej.:
IF Round( x, 2 ) > Round( 0.05, 2 )
Afortunadamente, esto no hay que hacerlo siempre. La inmensa mayoría de las veces no es necesario, aunque sí habrá que hacerlo cuando el resultado sea crítico.
Y por cierto, para aquellos que utiliceis algún motor SQL, sabed que existe el mismo problema. Yo mismo lo he visto, cuando p.ej. en un asiento contable que está perfectamente cuadrado, sum(debe) - sum(haber) no daba 0. En ese caso, tuve que cambiarlo por round(sum(debe),2) - round(sum(haber),2)
--
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
--
-
Andres Hocevar
- Mensajes: 141
- Registrado: Mar Sep 18, 2007 3:30 pm
DECIMALES... Algo raro
Yo he tenido esos problemas desde clipper, de manera que como disciplina
me acostumbre a limitar el nro de decimales a la hora de hacer
comparaciones, como dato curioso tambien a veces pasaba que 0.00 era
diferente a -0.00.
Saludos
El 30/01/2011 7:32, Jose F. Gimenez escribió:
> Paco y todos,
> el problema no es Xailer, ni xHarbour, ni BCC. El problema está en la
> forma de manejar internamente los números decimales por parte del
> coprocesador matemático.
> La familia x86 de Intel y AMD (y supongo que todos los demás micros
> actuales) siguen la norma IEEE-754, lo que significa que los números se
> guardan internamente en formato binario. Pero la conversión de números
> reales de decimal a binario no siempre es exacta. A veces hay pequeñas
> diferencias, y estas diferencias se ven incrementadas al realizar
> operaciones. Aquí teneis una explicación:
> http://en.wikipedia.org/wiki/Floating_p ... cy_problem s. Me temo
> que está en inglés porque no lo he encontrado en español, pero podeis
> traducirlo con google y se entiende bastante bien.
> La mejor solución (aunque sé que es un coñazo de cuidado) es utilizar
> Round() en las comparaciones. P.ej.:
> IF Round( x, 2 ) > Round( 0.05, 2 )
> Afortunadamente, esto no hay que hacerlo siempre. La inmensa mayoría de
> las veces no es necesario, aunque sí habrá que hacerlo cuando el
> resultado sea crítico.
> Y por cierto, para aquellos que utiliceis algún motor SQL, sabed que
> existe el mismo problema. Yo mismo lo he visto, cuando p.ej. en un
> asiento contable que está perfectamente cuadrado, sum(debe) - sum(haber)
> no daba 0. En ese caso, tuve que cambiarlo por round(sum(debe),2) -
> round(sum(haber),2)
>
> --
> Un saludo,
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info
me acostumbre a limitar el nro de decimales a la hora de hacer
comparaciones, como dato curioso tambien a veces pasaba que 0.00 era
diferente a -0.00.
Saludos
El 30/01/2011 7:32, Jose F. Gimenez escribió:
> Paco y todos,
> el problema no es Xailer, ni xHarbour, ni BCC. El problema está en la
> forma de manejar internamente los números decimales por parte del
> coprocesador matemático.
> La familia x86 de Intel y AMD (y supongo que todos los demás micros
> actuales) siguen la norma IEEE-754, lo que significa que los números se
> guardan internamente en formato binario. Pero la conversión de números
> reales de decimal a binario no siempre es exacta. A veces hay pequeñas
> diferencias, y estas diferencias se ven incrementadas al realizar
> operaciones. Aquí teneis una explicación:
> http://en.wikipedia.org/wiki/Floating_p ... cy_problem s. Me temo
> que está en inglés porque no lo he encontrado en español, pero podeis
> traducirlo con google y se entiende bastante bien.
> La mejor solución (aunque sé que es un coñazo de cuidado) es utilizar
> Round() en las comparaciones. P.ej.:
> IF Round( x, 2 ) > Round( 0.05, 2 )
> Afortunadamente, esto no hay que hacerlo siempre. La inmensa mayoría de
> las veces no es necesario, aunque sí habrá que hacerlo cuando el
> resultado sea crítico.
> Y por cierto, para aquellos que utiliceis algún motor SQL, sabed que
> existe el mismo problema. Yo mismo lo he visto, cuando p.ej. en un
> asiento contable que está perfectamente cuadrado, sum(debe) - sum(haber)
> no daba 0. En ese caso, tuve que cambiarlo por round(sum(debe),2) -
> round(sum(haber),2)
>
> --
> Un saludo,
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info
-
Marcelo Coelho Silva
- Mensajes: 269
- Registrado: Sab May 31, 2008 4:49 pm
- Ubicación: Brasil
- Contactar:
DECIMALES... Algo raro
Senhores,
Este é um Problema que se tem desde o CLIPPER. Ficando hoje no xHabour.
í‰ vergonhoso um problema deste (que não acontece em todas as linguagens)
não ter sido resolvido ainda, o que traz grade transtorno a muitos.
Provavelmente , por existir como sair do problema (Round(), etc.), os
colaboradores do xHabour não vejam estes erros matematicos com a
prioridade devida. Até pelo fato de ninguem ficar reclamando deles.
Parabéns ao Francisco M. Garcia , por ter retornado com esta questão.
Obrigado,
Marcelo Coelho Silva
Brasil.
Em 30/01/2011 10:02, Jose F. Gimenez escreveu:
> Paco y todos,
> el problema no es Xailer, ni xHarbour, ni BCC. El problema está en la
> forma de manejar internamente los números decimales por parte del
> coprocesador matemático.
> La familia x86 de Intel y AMD (y supongo que todos los demás micros
> actuales) siguen la norma IEEE-754, lo que significa que los números se
> guardan internamente en formato binario. Pero la conversión de números
> reales de decimal a binario no siempre es exacta. A veces hay pequeñas
> diferencias, y estas diferencias se ven incrementadas al realizar
> operaciones. Aquí teneis una explicación:
> http://en.wikipedia.org/wiki/Floating_p ... cy_problem s. Me temo
> que está en inglés porque no lo he encontrado en español, pero podeis
> traducirlo con google y se entiende bastante bien.
> La mejor solución (aunque sé que es un coñazo de cuidado) es utilizar
> Round() en las comparaciones. P.ej.:
> IF Round( x, 2 ) > Round( 0.05, 2 )
> Afortunadamente, esto no hay que hacerlo siempre. La inmensa mayoría de
> las veces no es necesario, aunque sí habrá que hacerlo cuando el
> resultado sea crítico.
> Y por cierto, para aquellos que utiliceis algún motor SQL, sabed que
> existe el mismo problema. Yo mismo lo he visto, cuando p.ej. en un
> asiento contable que está perfectamente cuadrado, sum(debe) - sum(haber)
> no daba 0. En ese caso, tuve que cambiarlo por round(sum(debe),2) -
> round(sum(haber),2)
>
> --
> Un saludo,
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info
Este é um Problema que se tem desde o CLIPPER. Ficando hoje no xHabour.
í‰ vergonhoso um problema deste (que não acontece em todas as linguagens)
não ter sido resolvido ainda, o que traz grade transtorno a muitos.
Provavelmente , por existir como sair do problema (Round(), etc.), os
colaboradores do xHabour não vejam estes erros matematicos com a
prioridade devida. Até pelo fato de ninguem ficar reclamando deles.
Parabéns ao Francisco M. Garcia , por ter retornado com esta questão.
Obrigado,
Marcelo Coelho Silva
Brasil.
Em 30/01/2011 10:02, Jose F. Gimenez escreveu:
> Paco y todos,
> el problema no es Xailer, ni xHarbour, ni BCC. El problema está en la
> forma de manejar internamente los números decimales por parte del
> coprocesador matemático.
> La familia x86 de Intel y AMD (y supongo que todos los demás micros
> actuales) siguen la norma IEEE-754, lo que significa que los números se
> guardan internamente en formato binario. Pero la conversión de números
> reales de decimal a binario no siempre es exacta. A veces hay pequeñas
> diferencias, y estas diferencias se ven incrementadas al realizar
> operaciones. Aquí teneis una explicación:
> http://en.wikipedia.org/wiki/Floating_p ... cy_problem s. Me temo
> que está en inglés porque no lo he encontrado en español, pero podeis
> traducirlo con google y se entiende bastante bien.
> La mejor solución (aunque sé que es un coñazo de cuidado) es utilizar
> Round() en las comparaciones. P.ej.:
> IF Round( x, 2 ) > Round( 0.05, 2 )
> Afortunadamente, esto no hay que hacerlo siempre. La inmensa mayoría de
> las veces no es necesario, aunque sí habrá que hacerlo cuando el
> resultado sea crítico.
> Y por cierto, para aquellos que utiliceis algún motor SQL, sabed que
> existe el mismo problema. Yo mismo lo he visto, cuando p.ej. en un
> asiento contable que está perfectamente cuadrado, sum(debe) - sum(haber)
> no daba 0. En ese caso, tuve que cambiarlo por round(sum(debe),2) -
> round(sum(haber),2)
>
> --
> Un saludo,
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info
Att.
Marcelo Coelho Silva
Brasil.
Marcelo Coelho Silva
Brasil.