Need some help from the math wizards.

A couple of us have been working with prim drift for the last month. I have come to the conclusion that there is no prim drift or float errors and feel I have the evidence to support this conclusion. Milo has gone ahead and bug reported it but this problem has been with us for way too long. If anyone can think of anything more to help trace the problem feel free to comment. The thread was started in current version feedback which is probably the wrong place for it but here is the link:

/142/d3/145466/1.html

See http://en.wikipedia.org/wiki/IEEE_754 for the iee float format used in sl.

You'll see that the mantissa is only 23 bits. If the float is normalised then the first mantissa bit will be assumed to be 1 and not stored, so really accurate to 24 bits.

Now 2 to the 24th is about 16 million, ie 16,000,000, which I would call 7 and a half decimal digits.

At the eastern and northern end of a sim you are looking at values like 234.567 in your edit boxes. That is 6 digits and only guarded by 1 1/2 digits.

On the other corner, SW, you might enter 5.123 and that is only 4 digits, so I would expect a much larger guard digit count to keep them stable.

Now consider that LL and SL are a work in progress and there would be a need to store lots of stuff in ascii for text viewing purposes, eg checking the backup worked properly is most easily done by checking a text version ot the numbers. So I would think there would be lots of binary to/from text conversions. Now with a math unit working 80 bits at a time, I would not have thought that the actual manipulation of numbers is at fault, but that it might be the decimal text digits that are causing problems.

Just my $L3 worth.

Woot!!!! That's it!. That is the answer and it is not good. Thank you Ed. It shows up clearly on this page:

http://www.h-schmidt.net/FloatApplet/IEEE754.html

Try entering any number and converting it.

"Rounding errors: Not every decimal number can be expressed exactly as a floating point number. This can be seen when entering "0.1" and examining its binary representation which is either slightly smaller or larger, depending on the last bit."

So we are basically screwed. Unless each and every piece in a build has a location ending in .0 or .5, then there will be some drift upon each sim restart. (actually that statement was not entirely correct. There is no float correction if you use multiples of these these fractions 1/2,1/4,1/8,1/16,1/32,1/64,1/128,1/512,1/1024 etc.) Any object that moves, such as a door and the problem is made worse. Using a rocking motion it is easy enough to get some linksets to move meters a day. But even a simple door if the linkset is in the wrong place can move a noticeable amount after only working a few times. Even static pieces when in a linkset can be a problem. We have seen cases now of them moving .00013 to .00046 after just one sim restart.

Give LL a heart attack! Suggest they use doubles, only twice the storage space!

In practice, won't objects just tend to settle into the closest 'quantum' state representable by an IEEE float? Obviously there are issues if you do math on their positions, but then this is why most moving objects in SL (e.g. doors) implement drift correction, and store some datum to jump back to, instead of doing inverse math operations to get there.

Last time i harassed them about making changes to the language, they said they wouldn't till Mono.

In an ideal world you would be right, but it depends on how the sim data is stored. For there to be drift I believe that we are dealing in two domains, the 4 byte binary float, and the x number of decimal digits representation of that float and that the conversions are not symmetrical. LL can either replace the digit representation with binary or make the conversions totally symetrical. I can't think of any other way this drift could be caused, but I am happy to consider any other theories.

This ball is firmly in LL's court.