LSL floating point accuracy

now I am officially disappointed. There appear to only be about 8 digits of precision to LSL's floating point calculations. Are they really only using single-precision? This makes it very difficult to perform accurate astronomical calculations in-world, and I really don't want to have to devise a double-precision library for LSL

Say it isn't so!

- C

'fraid so

I think of it as 7 decimals - 23 bits of mantissa, 8 bits of exponent, and 1 sign bit.

Let us know if you make a double-precision library. I think a lot of people around here would sure love one

and how slow would *that* be? Using lists for aggregating the numbers. OMG.

*shudder*

- C

Indeed. A couple of us have for certain situations... I did for my pinball machine.

I think Strife's done enough ranting on this subject for the three of us, though.

Well there's always reduction in strength tricks like casting float * 1e7 into integers because there are more significant digits in integers. Also, since the granularity of SL seems to be at +/- 0.001 you'd have two junk digits to swallow rounding errors.

I'm not sure what you are doing with astronomy, but many of the World functions return normalized (or normalizable) vectors so you should be safe with the range of integers. Remeber also that the sun moves across pi radians of sky in 3 RL hours, and does that in ten second "ticks" which is 4.85e-5 radians (or 1.45e-4 radians at night).

Of course you'd have to hack up some integer trig functions if you wanted to do calculations, but I'd recommend exporting the data via e-mail or XML-RPC for external analysis. This is, after all, astronomy which is not known for needing speedy analysis. If I remember right, we sent people to the moon using slide rules, so you might not need all that much precision.

Lets see, floats are evil. LL's float -> string implementation is lazy. I just hope they give us doubles. (LL don't bother with long doubles, Microsoft hasn't implemented them in thier compiler; they use doubles instead)

It's been a while since I've said anything about this topic.

The percion of your slide rule is based on how long it is and how small they printed the text. We had an Otis King model L. The model L would be about 5 1/2 feet unrolled (it's a cylindrical slide rule).

I'm thinking about writing a new float to string function that will be a combination of logs and standard f2s, which should make things faster. My method of using a mantisa of 55 bits isn't exactly fast. linky

As I suspected, Strife *is* a rocket scientist

I'm touched you think so, but physics isn't really my thing. Alot of work and really annoying since you have to use floats...

I just put out an updated version of FloatToSci function. should be a bit faster and easier to read. Mostly rewrote much of the logic to reduce the number of function calls.

well you can always *see* the moon

But doing really accurate phase-on-the-moon calculations (always useful for correlating bug reports) requires a fair few sig-figs. Mind you I could probably pick a different initial new moon to calculate from but then I'd had a whole *heap* of constants to re-figure.

It's also woth realizing that the *primary* applications for the first really big floating point formats (VAX huge-floats come to mind) were both astronomy and ... oddly enough ... surveying. Tiny angles multiplied by long baselines

- C

OK, I started writing an extedned precision library based on Knuth, using a list of 3 ints; 1 exponent, and 2 mantissa. However, seeing Strife's code makes me wonder if I might just be better off using a pure string representation of extended precision floats. So my question is about the big-O behavior of the different access methods.

1 - Are LSL lists O(1) for accessing a random element? Just the head? Head and Tail?
2 - Is llGetSubstring() O(1) for constant length substrings?
3 - Is there an O(1) way to convert a single character in LSL to an int that is faster than llGetSubstringIndex("7", "0123456789"?

Any other ideas about this approach will be duly noted

- C

Caoimhe,

Cool, look forward to seeing it.

Yes, yes, no.*


*True enough for all intents and purposes

It would be interesting to write a smallish wiki reference on LSL complexity.
Please post your findings, Caoimhe

I've started that on the bytecode page on badgeo.

Feh, all the cool kids are using fixed-point math anyway.

(Ha ha, only serious).

Yeah, no kidding. FPM would probably solve all the little floating point problems we've had with rotations. Rounding them to the nearest half degree is simply silly if you ask me, but what we had before wasn't exactly nice and polished either.