>Are you saying that other languages will return v1=v2==.T. then int(v1)=int(v2)==.F.?

No, I'm saying that Fabio can't ? a variable and observe the result, which is dependent on several factors that govern the binary to decimal conversion, and then be 100% sure that he can create a constant that will be converted from decimal back to the exact same binary representation.

Consider this extreme case to prove the point:

set decimals to 2
x = 1.0 / 3.0
? x && observe that VFP tells you the value is 0.33

y = 0.33 && now write a line of code based on the above observation

? x, y, x = y && says x != y and Fabio complains that VFP is not deterministic

Xbase was never designed to truly handle floating point values. Fortran and C have always been much better at it. In Xbase when you think you are trying to work near the "limits" of accuracy then you are expecting too much *L*

>Is that what the C code example posted by Gregory illustrates? (I don't have a C environment to easily test the code he posted, and he doesn't draw a conclusion about it...)

Gregory's code is just showing how one needs to deal with floating point arithmetic when you want to get integer results out of it.

>It seems to me that if v1=v2, then there shouldn't be an issue about them not being "exactly" alike...

But you see the fact that x was not equal to y right? The int() is really a red herring in the discussion. x had a value of 0.3333333333333333333333333333333333333333333333333333 and it takes an infinite number of 3s to represent the value. We work with 32 bit computers so the accuracy is even further limited by truncating the binary representation to 32 or 64 bits, this happens in every programming language.

>Particularly when converting to decimal yields an identical fractional value for both. I guess I have the same lack of understanding as Fabio of how a "Double" floating point data type works.

If you want the best floating point accuracy use C or Fortran, not Xbase.