Prim Drift Good Bad news

Great, that means it ought to be possible to kill prim drift of whole linksets. Based on Gearsawe's results, that single prims don't seem to drift, and pairs of linked cubes don't seem to drift, the guess was that its something to do with float errors in calculating the geometric center. That somehow the geometric center is being stored rather than the position of the root prim.

I recently made a script.. that took the number 1, and subtracted 0.01, and looped until it hit zero. Here's the problem.

It never "HIT" zero!

Almost 3 cycles out of the gate, we were receiving numbers like 0.9600001 (don't remember exactly, and didn't make a log)

So, by the time that we got to "less than 0.01" it was like 0.000009 and then -0.009999991. The script just went screaming along like that til I finally figured out how to stop it without deleting it.

But there was no prim MOVEMENT involved in this.. I was planning on using the number to set transparency... but at the testing stage it was just "saying" the numbers in chat. I don't think we're dealing with a coordinate problem so much as a backend issue with either LSL or the processors being used... it's a simple inability for the scripting system to actually DO math.

Tomorrow, if I remember, I'll rewrite this script again to post a demo.

No no, that's just the usual float inaccuracy (which is a problem with floats in any system, not just SL), combined I suspect with testing on if(my_float == 0.0). Never check floats for equality, it doesn't work. Instead you'd be better using if(my_float <= 0)

One of the last things checked last night was a single prim. .5 meter square with shear of -.10 and .30. No drift on sim restart. BUT introducing rotations on the 3 axis and restart and the drift showed up. So the adventure continues. Will try today single prim again in various combinations of shear and rotations to hopefully rule out one or the other to narrow it down.

Is it possible to change the floating point representation by multiplying the numbers or something?
If you think about, the range of a floating point number is HUGE, yet in SL we only have a limited amount of values (e.g max height we can set an object to is 256.0), plus our limited decimal places (5?) this means that the full accuracy of a floating point number should be sufficient to represent all our numbers without drift, if we use some modifier when storing and interpreting positions.

But it still doesn't really explain why the drift is occuring for restarts, as if the floating point number is stored as accurately as it is handled, then it should be perfectly reproduceable when the sim loads up again. But that does not appear to be the case.

I was thinking about that last night. Why was IEE 754 setup like it was. If an extended number of decimal points was not needed, for example if a maximum of 6 was good enough. Then why couldn't they have multiplied the integer/float by 1000000 instead. Then there would be no in built error. But it is the system that is used by all computers and at the time it was created was logical I guess. It is definitely an American creation because normal American fractions are good numbers: 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, 1/256, 1/512, 1/1024 etc. So looking at it, you would have to come to the conclusion that if IBM or Bill Gates or whoever would have been from Germany then present day computing would be different and based on multiples of 10. Even SL would be different and a no tier piece of land would be 500 sqm instead of 512???

Still running through combinations in Beta this morning, but one interesting preliminary observation. If you have access to estate tools then you can try this.

Create a box .5 meters square. Rotation = <351.40, 6.05, 22.35> shear = -0.10, 0.30

Another with same rotation but shear of -0.50, 0.50

(The boxes are not linked)

Use something like the following script to display to 6 decimal places instead of 5:

default{
    touch_start(integer total_number){
        vector pos = llGetPos();
        llSetText((string)pos.x + "," + (string)pos.y + "," + (string)pos.z, <0,0,0>,1);
    }
}

Then restart the region. The one box with -0.10, 0.30 shear will show drift and the other box won't.

Binary numbers aren't an American/German cultural difference, last I checked Americans generally have 10 fingers as well. Computers work well with binary, which is why it's used.

The differences in different shears I'm guessing are further evidence of it being a geometric center vs root position issue.

1/10, 1/3, 1/5 etc do not express exactly as a binary number. The American standard fractions do all convert exactly. Please show one number that converts exactly that is not equivalent to a number based on 1/2, 1/4/, 1/8, 1/16, 1/32 etc.

You did notice that the example I gave were single prims and not a linked set?

A single prim with Rotation = <351.40, 6.05, 22.35> shear = -0.10, 0.30
will drift <0.000015, 0.0, -0.000002> after every restart and it is accumulative.
With a starting position of <236.0, 246.0 ,28.0> after 5 restarts you end up at
<236.000076, 246.0, 27.999990>.

There are a multitude of ways to get worse drift using linksets but I have been searching for the lowest common denominator. Rotating a linkset speeds it up considerably also but it is still does not help narrow down the problem as much. Now that the problem of floats is out of the equation then it is easier now that a single prim that drifts has been found. Using diferent variations of shear/rotation to see the results. But it is infuriatingly slow having to wait for a restart after each set of adjustments. But slowly the question to be asked is being refined. Now instead of how is a linkset stored in the server, it would be how are shear and rotation stored and how would this possible affect position. This problem has been around probably from day one with no progress from LL. Without breaking the problem down to the constituent parts I would not expect them to finally come up with a solution by just telling them once again that linksets drift for some unknown reason.
We were fortunate though and I wanted to thank Milo Linden. Gearsawe and I both approached him on the same day asking to have different capabilities. Gearsawe needed to be able to restart a region and I needed access to the estate tools to do some research on script performamance. Milo created a place and an enviroment to make this possible. My research was wrapped up quickly and I became intrigued by the problem and have been in it ever since.

What are these "American standard fractions" you're talking about? As far as I can see you're just talking about fractions with denominator a power of two (which yes, I would expect to be the numbers that floats deal well with). I can't think of anything particularly American about such numbers. Perhaps you're thinking about Imperial measurements rather than metric?

Decimal equivalents of inch fractions.

If this is an argument brewing then I am going to get back to working on the problem. Is there a reason you want to keep trying to point out flaws instead of A. Ignore it or B. come to your island in Beta and give it a try??????

Yes. The center of the bounding box of a skewed prim is not the position of the prim itself. For some skews, you get another power of 2 fraction, for some skews you don't.

I can think of one. 3/4. That'll represent perfectly as a binary fraction. Oh, you're going to argue that I "based" that on 1/2 and 1/4? Well, then I'll just throw out 0.8125 or something, which will also represent nicely as a binary number with few digits (and which I got by adding a few of your fractions together). The point is that this is just how it works: the numbers are stored in base 2, so of course these fractions with denominators of base 2 (also equivalent to 2 to a small negative power... aka, 2 is the base of exponentiation) will work out nicely. The process of converting a fraction to base 2 is exactly equivalent to figuring out what sum of those "American standard fractions" as you call them will add up to the number.

All numbers in a computer are stored in base 2, binary. They're just formatted in base 10 whenever they're printed out because that's generally all most people can quickly understand. If we wanted to make numbers like 1/10 and 1/5 easy to represent internally, the entire computer could be based on base 10, but it's not, because base 2 is the easiest to write circuits for. Inevitably, when converting between our preferred base, 10, and binary, we're going to find that some of our nice clean numbers can't be represented without an infinite number of digits. It's like how 1/3 can only be represented in base 10 as 0.333333333333333.... with an infinite number of digits.

OMG Lex!! Come on now. 3/4 is a multiple of 1/4. .8125 is the decimal equivalent of 13/16, you can also use 15/16 or 15/32 or even 15/1024 and I never stated otherwise.

I've written a number of functions for dealing with floats [in LSL]. Such that they are exposed to the user in such a manner to represent their true form on the server and thier limits.

Specificaly:
Float Union Integer & FloatCompare (second & third script boxes on the page; no documentation provided).
Float2Hex & Float2Sci(documentation provided)

Thank you Strife. Hopefully it will keep others from wasting time on a dead end like I did. But I still learned and that is all that matters. I am sorry to admit that I have always been somewhat of a geek and actually found reading about IEEE interesting. Actually it reinforces my idea that if the computer would have been invented in a country with the metric system that we would not be having these problems and would be using IEEE 854 instead. It is not really a matter if one being harder to implement over the other. I am old enough to remember Fortran and now I like the rest of the world wonder why in heck IBM went with IEEE 370 and base 16. So using IEEE 854 and base 10 is not far fetched. If you own a handheld calculator you are already using it.

Well Jesse would you have liked it if the history of all todays computer were developed from here.

http://www.icfcst.kiev.ua/MUSEUM/Brusentsov.html

this might give your existing head ache a head ache.

WOW Great link Gearsawe! I will have to look up this "natural" numbering system of his sometime. Sounds intriguing. Just think 13 years after he had already invented that computer I was still using a slide rule in Junior High(yep I am that old). But then add another 8 years to that and I held I think what was a TI 95 in my hands. OMG bad memory. I think it was the TI 95, it had a small wallet of magnetic strips, some were preprogrammed and some blank. Forgot the capacity of each but I was still able to write a nice, neat trig program on one that I used for years. It would take any 3 variables from any type of triangle and spit out the results for sides and angles.

It's my understanding that 854 is an extension of 754 to support base 10 arithmetic instead of base 2. Furthermore 854 was created for the world of calculators, in which they wanted to avoid the prospect of having to convert between base 10 & base 2 (by avoiding the conversions they can reduce the complexity of input & output; which makes for a less expensive product). 854 base 10 is largely unpopular because it just doesn't fit in a binary architecture.

A much more reasonable suggestion has been the proposed revisions to 754. This revision departs from the normalization requirement of the floating point binary counterparts, allowing it to maintain zero places (good for currency calculations). The exponent of this decimal version, is applied like base 10 instead of binary. It maintains the portability of binary and avoids it's pitfalls. It will probably be 10 years before x86 or x64 chips start hitting the consumer market supporting this (as they are still adding functions to the command set). Much more likely to see math co-processors first (like back during the age of the 386 with it's 387fpu).

http://www2.hursley.ibm.com/decimal/

I totally agree, this stuff is rather interesting.