>Fabio,
>
>>Is 2.0500000000 a valid float value ?
>>if yes then 2.05000000000 is valid too,
>>if no then 2.05000000000 is not valid too.
>
>They are different when you look at the compiled program:
>

>0x00000050 : 16 00 54 F7 00 00 10 FC FA 10 0A FF FF FF FF FF    ..T÷...üú..ÿÿÿÿÿ
>0x00000060 : 9F 69 40 CC FD FE 16 00 54 F7 01 00 10 FC FA 11    Ÿi@Ìýþ..T÷...üú.
>0x00000070 : 0B FF FF FF FF FF 9F 69 40 CC FD FE 03 00 55 02    .ÿÿÿÿÿŸi@Ìýþ..U.
>

>The first value is 10 0A, that is, 16 digits long and 10 decimal places. The second one is 11 0B, hat is, 17 digits long and 11 decimal places. This causes VFP to round up the first value to this precision before using it for the INT() operation. Thanks for pointing out this bug in Guineu, though. ;-)
>
>In any case, the point is, floating point operations are floating point operations, and decimal operations are decimal operations. You cannot look at decimals values and use those as an argument for floating point issues. Going back and forth between the two is a conversion between data types as is casting to an INT(), which was my original statement.

I know this feature of VFP, and I wrote "An explain can exists, ..."

The attempt, on VFP,
to emulate the decimal numbers using the float64 is very bad;
it store a decimal format for every number,
with bad results

x=2.0500000000*100
y=2.05000000000*100
* are equal : YES! Two numbers are equal but the integer part is different!
?  x=y , INT(x)=INT(y)   && .T.  .F.

Another point is that float
makes it impossible to make calculations in Decimal(N,M) with MSSQL
and replicate results in VFP.

Round() is not usefull
because 2.05 doesn't exists on float64 space
and then we can not use a number that does not exist

? EMPTY(2.05-ROUND(2.05,2)) && return .T.