>The Problem still is there.
>The empty() Command delivers a false while the Value itself can be compared with 0.
>The empty() command obviously has a bug.
>Here's the Code again.
>
>clear
>local a, b, c, d,x
>a= -1
>b= -0.1
>c= 1
>d= 0.1
>x= a+b+c+d
>? empty(x)
>? x=0 &&This should also deliver a ".f." but it gives us a .t.
>
>I think Microsoft should repair this. I understand the floating point, but I never suspected it in any command from FoxPro.
>
>Here's a workaround code. But I think we could instanciate every FoxPro command like this one if we can not dely on the behavior. Also this slows down our programs a little bit.

In reality what is happening is (i did not count the zeros):

? x=0.00000000000000000000000000000000

This gives you .f. You must match the internal precision, which VFP should be smart enough to do.

Also

z=x
? z=x gives .t.

So if in you really want to have something you trust, then
#define ZERO 0.0000000000000000000000

and use that instead of Empty().

Floating point problems like this occur on all languages. The workaround is to be aware. VFP covers up most of them pretty well and maybe that's part of the problem.

FYI this is consistent with FPW26.

Clipper returns .f. for both cases.

Costas