Floats getting inaccurate very quickly

Hello everyone. I just experienced something odd with a simple script that I wrote to test something. The only thing I do is to add 0.2 to a global float in a timer and display the value. I noticed the value gets very inaccurate very quickly. Now I wonder if this is the way it's meant to work or if this is a bug with the script being compiled with the First Look and/or Linux version. I'm using First Look build 59036 on Linux.

Put this script in a box and observe:

As an experiment, compute the value two ways and compare...

integer i=0;
timer()
{
llSetText( (string)floatCounter, <1,1,1>, 1 );
floatCounter += 0.2;
fC = i*0.2;
i++;
// compare floatCounter and fC.
}

...or some such.

0.2 cannot be represented perfectly in binary floating point, so every time you add that, you are adding a little non-random noise as well. It adds up quickly. This is a well known problem in most languages.

A common solution is to use integers, scaled accordingly, and translate to human readable numbers only on demand.

LSL's use of float rather than double doesn't help either

Bring back BScaling

Personally.. how about actual math with actual numbers?

you know.. where 1.00 - 0.25 = 0.75, not 0.749
(and don't EVEN get me started on .125, .375, .625, and .875... GRRRR)

Did Linden Labs get a bulk discount for buying old Pentium chips or something?

This is a completely unfair complaint. Every modern CPU in every modern personal computer will have these inaccuracies. It's just how floating point computation on computers works! It's just not feasible to do "real math with actual numbers" as you put it. Or rather, it is, but they do it with binary numbers rather than decimal, and you lose some in the conversion. 0.2 is quite likely to be represented as a repeating binary floating point number, since that's the most exact binary representation you can get.

That said, 0.125, 0.375, 0.625, 0.25, and 0.75 (for example) SHOULD represent precisely. Did you actually take your example equation from a script you'd tried in SL?

*koff*

CL-USER> (let ((x 0))
           (dotimes (i 10000)
             (setf x (+ x 0.2)))
           x)
1999.8058
CL-USER> (let ((x 0))
           (dotimes (i 10000)
             (setf x (+ x (/ 2 10))))
           x)
2000

That would be Lisp being smart. The result would be dependent upon the platform and Lisp implementation. (congrats on mentioning an RPN language).

What does it do, keep around a numerator and denominator and do divisions analytically?

I stand by what I said earlier: it's not feasible to do this kind of thing in a system like SL.

Incidentally, Lisp is Polish, not Reverse Polish. In RPN, the operator follows the operands.