🚀 go-pugleaf

Albert Lo wrote:

> I think your bug means the following output for "expected" zero.
> The reason should be same to that we never compare floating point number
> with zero.
> It depends on the precision of IEEE format of floating point number.
> -1
> -0.9
> -0.8
> -0.7
> -0.6
> -0.5
> -0.4
> -0.3
> -0.2
> -0.1
> -1.38778e-016
> 0.1
> 0.2
> 0.3
> 0.4
> 0.5
> 0.6
> 0.7
> 0.8
> 0.9
> 1

There is no bug here. The fraction 0.1 does not have an exact floating point binary
representation. Therefore when you start at -0.1 and continually add 0.1 then at
each step there is a small round-off error. The default conversion in java is to display
floating point numbers with 6 significant figures. For this display accuracy the numbers
-1 to -0.1 appear to be reproduced exactly, but the next step produces the entry that is
not zero to 6 significant figures. Try it with float and there will be other differences.

So it's not a bug, just a property of floating point arithemtic.

Barry Adams
(barry@bethel.cs.laurentian.ca)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx