Yes, I have also have noticed the rounding problem from time to time. As you know decimal digits has no absolute value binary, so a conversion is necessary, a conversion which nexer is 100% exact. So you must always have that in mind. Or you can multiply your numbers to make them integers, and divide back to show the numbers with decimals.


>But Marvin does highlight a problem:
>
>

>local z
>z = 0
>? empty(x)  && returns .T. and x = 0
>x = 1-1
>? empty(x)  && returns .T. and x = 0
>

>
>but Marvin's little calc example which results in a zero value returns .F. on the empty test. Obviously there is a rounding issue internal to VFP. Check this:
>
>

>* Marvins code:
>
>* set variables
>a= -1
>b= -0.1
>c= 1
>d= 0.1
>
>* do the calc
>x= a+b+c+d
>? empty(x)  &&  x is zero but empty() returns .f.
>
>release all
>
>* set variables
>a= -1
>b= -0.1
>c= 1
>d= 0.1
>
>* now reverse the calc order
>x= d+c+b+a
>? empty(x)  &&  x is still zero but empty() now returns .t. !
>

>
>
>
>
>
>
>>Hi Jos,
>>
>>I agree completely.
>>
>>>>Hi I just had a look at this bug, and wanted to warn again:
>>>>
>>>>Try:
>>>>
>>>>clear
>>>>local a, b, c, d,x
>>>>a= -1
>>>>b= -0.1
>>>>c= 1
>>>>d= 0.1
>>>>x= a+b+c+d
>>>>? empty(x) &&The Value should be empty... but FoxPro tells us it isn't
>>>>? x=0 &&This should also deliver a ".f." but it gives us a .t. which is correct
>>>>
>>>>That means...
>>>>
>>>>Be sure not to use empty with unrounded Numeric Values -or-
>>>>don't use empty()
>>>>
>>>>Greetings
>>>
>>>
>>>Marvin, personally I think a numeric value of zero should not return .T. for empty() becasue zero is a valid value for a numeric.