>Hi,
>
>i have understand this:
>vfp numeric variables or litterals is a double with a format.
>
>Then, computations is correct, but value show can change.
>
>Then, why comparison of values can fail ?
>
>

>? 1/1999999 = 0
>* ok : false
>? 1/2000000 = 0
>* NOK : true
>x = 1
>? x/2000000 = 0
>* ok : false
>? 1/2000000.0 = 0
>* ok : false
>? 1/20000000.0 = 0
>* NOK : true
>

>
>For any unknown information, VFP use a ROUND(,5) for litterals interger
>divisions.
>
>For correct computation, is need to add decimals zeros, but the number of
>zero change the values ( not the display format ) !
>
>For me this is a bug.
>
>Fabio

The problem stems from a general problem with floating-point calculations in general. In a programming language like C or Pascal, you are not supposed to calculate two floating-point numbers for equality. Because of possible rounding errors, two numbers that should be exactly the same, will sometimes not be so.

Instead, you should compare whether the difference of the two numbers is smaller than some small constant, for instance: abs(A - B) < 1e-6.

I understand VFP does this automatically, to allow you to use "=" in comparisons.

So, frankly, I am not surprised by the fact that the comparison returns .T. What surprises me a little more is that an expression like:

? 1/20000000.0 * 1e6 = 0

also returns .T. It seems that at some point, very small quantities get treated as zero, in subsequent calculations.

I am not sure about work-arounds - except, perhaps, avoid very small quantities in the first place (if you don't want them to be treated as zero). For instance, my last example can be changed to:

? (1 * 1e6 / 20000000.0) = 0

Small quantities are avoided in this case; VFP shows .F. as expected.