Clipper/FiveWin - Suma incorrecta. Comparación de cantidades

Hola a todo el mundo. Sois cojonudos.

Una pequeña duda que tengo con clipper 5.2.

Al comparar el resultado de una suma con dos decimales, clipper me dice que la suma no es correcta, cuando yo se que si es igual. ¿Alguien sabe a que puede ser debido? En concreto yo pongo en el programa algo así:

if 13124.59 + 8749.72 = 21874.31
@ 10,10 say "la suma es correcta"
else
@ 10,10 say "esa suma no es correcta"
endif

He hecho la prueba con distintas cantidades y siempre me funciona, excepto con las dos cantidades que he puesto anteriormente, que me dice que no es correcta.

Bueno, yo he resuelto la forma de que me acepte la comparación multiplicando todas las cantidades por 100, para eliminar los decimales y entonces si me dice que es correcta la suma.

Un saludo. Y gracias de antemano.

Prueba comparando con el operador ==
El operador = y el operador == no arroja siempre los mismos resultados

Verifica y comenta

Pues con el operador == me sigue diciendo que la suma es incorrecta. La curiosidad es por las cantidades que son, que solo me ocurre con esa cantidad. Para explicar un poco, el programa tiene que filtrar una base de datos donde la cantidad introducida en dos de los campos, debe de ser distinta a otro campo. Y justo el registro que tiene como valores los que he puesto anteriormente, no debería de salir filtrado, pues evidentemente la suma de las dos cantidades es igual a la tercera. Bueno, Gracias por la Respuesta y Saludos.

Yo acabo de detectar un problema similar, de fallo con los decimales. yo tenia una aplicacion hecha en clipper para generar el disquete de domiciliaciones bancarias de los recibos mensuales de un club deportivo. Esta aplicacion lleva funcionando 7 años sin ningun problema. Ahora con el cambio al euro hago los cambios para que los importes salgan en euros, y a la hora de calcular la suma de los importes parciales, en algunos casos la suma que me calcula el programa es +- 0,01 que la suma real y los bancos devuelven el disquete por no coincidir la suma con los parciales. Voy a probar haciendo los calculos multiplicados por 100 para ver si asi lo soluciono y te contare la experiencia.

Saludos.-

He comprobado esta mañana que haciendo los calculos por 100, tambien tenia algún problema. Al multiplicar por 1000, los problemas me han desaparecido. Pero me resulta muy curioso que clipper falle en eso. Dichoso euro. Lo que comentas tu tambien me ha sucedido a mi, supongo que es problema de los redondeos. Ten en cuenta, que cuando pasas un total de una suma en pesetas a euros, es distinto que si ese total lo haces de sumar las cantidades en euros.

Venga, Saludos. Y Suerte.

Que tal amigos del Foro, aca de nuevo en la Lucha, el inconveniente que planteo Peter y Lucas no me ha sido exento, aparentemente las operaciones matematicas reflejan muchos mas decimales que los visuales, esto era muy pocon en equipos sin procesadores matematicos, soluciene el problema haciendo FIX a los decimales;

Explico
x1= 344344.23 + 45954.21
x2= 390298.44
if str(x1,12,02)=str(x2,12,02)
? "iguales"
end

Prueben y comenten

Saludos
Raúl Noguera
Cagua - Venezuela

¿Donde está el problema, en el compilador de Clipper 5.3 ?

Vamos a ver, sumo dos campos numericos de doce enteros y dos decimales en dos variables (nDebe y nHaber), y las dos variables suman lo mismo.

Paso la diferencia a una nueva variable (nDife) cuyo valor, presentado previamente en pantalla es "0,00"

Hago la siguiente comparación:
IF nDife<>0
....
ENDIF
y en algunas ocasiones, aún siendo nDife "0,00", ejecuta las instrucciones de dicho IF .. ENDIF (Naturalmente poniendo:
IF STR(nDebe,12,2)<>STR(nHaber,12,2)
...
ENDIF,
no entra en este bucle)

¿ Donde está el error ? porque en las suma referidas, al ser una suma, no puede haber mas de dos decimales. Diferente sería si hiciera una multiplicación o división.

¿ Porque lo hace en ocasiones si en otras no?

Todo esto me pasa desde que utilizo decimales, por la cuestión del famoso EURO.

No me resigno a tener que cambiar todas las comparaciones que tengo a tipo caracter con el STR(n,12,2), al margen de parecerme una chapuza.

¿Comparas nDife con 0 o con 0.00 o con 0.0000..... ?
Tal vez esa sea la respuesta. SET DECIMALS TO solo afecta a la visualizacion de los valores mas no asi a la precicion interna
El uso de una buena funcion Rounded(..) seria mas practico que la conversion a strings de cada numero ....
Ahora bien el problema de la precision siempre se va a tener y si no prueben en sus propias calculadoras de ultima generacion lo siguiente
10/3 = 3.3333333 ahora si invertimos la operacion ....
3.3333333 * 3 = 9.99999999 no a 10 !!!!

He solucionado el problema que tenemos, "coma flotante" ( y que segun me han contado es tan antiguo como Clipper), de la siguiente manera:

Si en el programa voy a utilizar un máximo de cuatro decimales, defino en el PRG principal una variable publica numerica igualandola a a 10000:
nExp:=10000

Posteriormente y en cada comparación entre variables numericas hago lo siguiente:
nVarNum1:=12345.6789
nVarNum2:=12345.6789
IF INT(nVarNum1*nExp) >,<,<>,= INT(nVarNum2*nExp)
...
ENDIF

Hago lo mismo si comparo variables con el CERO:
IF INT(nVarNum1*nExp) >,<,<>,= 0
...
ENDIF

PD.- Me puedes enviar la funcion: Rounded(..)

Suelo solucionar este problema de la siguiente manera:
a) Cuando quiero comparar dos cantidades de dos decimales, lo hago asi:
IF Abs( a - b ) < 0.01 && Significa que son iguales redondeados
a dos decimales

b) Suelen producirse problemas en los resultados de productos y
cocientes, pues entiendo que la computadora trabaja siempre con
el máximo de decimales posibles. Entonces siempre redondeo los
productos y cocientes a la cantidad de decimales correspondiente,
por ejemplo:

a := Round( b * c, 2 )
Entiendo que este no es un problema sólo de Clipper, sino de
cualquier lenguaje

Saludos. Gracias