Bug or feature?

It's not a bug. This is a normal consequence of floating point calculations in any language (C, Tcl, perl - you name it). Many things on the web about this, but this is a good reference:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

Try doing x1-130810 and you'll see that x1 is a tiny amount below 130810 and hence when truncated it ends up as 130809. It's caused by the fact that 0.01 is an infinitely recurring sequence in binary, rather like 1/3 is 0.333 recurring in base 10 - and so if you truncate the number to a finite precision, you end up with rounding errors.

Regards,

Andrew.

Hi,

Neither a bug or a feature!  You show x1 as being 130810.0, but it may actually be internally represented as 130809.999997 (say), so it may display as 130810.0, but when you truncate the fractional part to make it an integer, you see 130809.  You can print more digits of a floating point number, e.g. using printf() to check this for yourself, something like the following:

 printf("%6.8f" x1) 
 => 130809.99999700

The default print representation of a floating point may give you up to 6 digits of precision, but only for about 7 significant digits, so if the number is already 6 digits 'wide', then you will only get one digit of precision and the number is rounded when it is presented to you.

I hope that this helps to answer your question, or at least helps you to understand what is happening.

Regards,

Lawrence.

 Many thanks for so detailed explanations and for the reference to very useful article

Best regards

Slawa