Jira for typecast from float to string

There's a Jira-entry for the typecast problem (float to string which produces false results).

http://jira.secondlife.com/browse/SVC-1604

It only has 4 votes - I think it could need some more...

in the JIRA it states that: 1.52345664367, typecast to a string, would result in 1.523457
This is what you can expect! A float don't carry more information than that.
A float has a 23 bit mantissa and one sign bit.
1.52345664367... truncated to 23 bits equals: 1.52345640960...
From that you can see: the typecast makes a very nice rounding on last significant digit to 1.523457
So I don't vote for it

floats in SL have a limited accuracy.

If you look close at a float value in SL you will find they are generally truncated at six digits after the dot. So, 0.000001 is the smallest float value you can get out of LSL.

If you need higher accuracy then, I'm afraid, you will have to use different methods to achieve that.

Really?
What about 1E-100?
For all I know it is a valid float number in LSL

The conversion doesn't work with six digits as well...

As I stated in another thread:

float test = 8.123456;
llOwnerSay("TEST: " + (string)test);

-> Will result in 8.123456

float test = 18.123456;
llOwnerSay("TEST: " + (string)test);

-> Will result in 18.123455

float test = 118.123456;
llOwnerSay("TEST: " + (string)test);

-> Will result in 118.123459

*****

When I do this in PHP:

$float = 118.123456;

settype($float, "string";

echo $float;

I will get EXACTLY 118.123456

I might not know enough about floats but I can hardly believe that PHP and LSL handle floats THAT differently...
The problem is not precision but accurate conversion from floats to strings, which obviously doesn't work the way it should.

PHP is probably using double precision floats. That does not remove the fact that there is a limit, it just pushes the limit

Any number that is less than 16 (after taking it's absolute value) cannot be guarantied to be perfectly represented with six decimal places.

I've written a couple of functions for handling this problem, in LSL neither requires a specialized parsing function:
Floating point hexadecimal notation - http://wiki.secondlife.com/wiki/Float2Hex
Floating point scientific notation - /15/28/28006/1.html

Dora,

Ok - I guess that clarified it a little... but still, what you write means that a number like 123.123456 can't be handled correctly in LSL due to these limitations? Isn't that a little weak? I mean, that's quite a small number and chances are, that one might end up with even bigger numbers.
So when I understand you correctly, a float like 1234567.1234567 would actually end up being an integer (sort of) with a value of 1234567? Means, any number bigger than 999'999 would end up as an integer - which - sorry if I repeat myself - sucks

That's too small for an 8-bit exponent. The smallest value expressible by a 32-bit IEEE 754 float is approx ±1.4e-45.

That is correct. But it is relatively accurate, better than one to one million

That is correct as well.

You have to look at what these numbers are used for, they are used for sizing and placing prims in a virtual world.
You can size a 10m prim within 10µ !
You can size a 1m prim within 1µ !
etc.
What more do you want?
You can place a prim from one corner of a region in the opposite corner accurate within 0.3mm.
Can you ask for more?

The beauty of floats is that the relative error is the same for large numbers and for small

Thank you for correcting me. 1E-45 is still a bit smaller than 0.000001

How many digits of precision that a "float" can represent is very dependent on the magnitude of the number being represented.

With a 32-bit representation, there are only 2^^32 (4,294,967,296) possible floating point numbers that can be represented with 100% accuracy. And exactly half of those numbers are between -1 and 1 (those with negative exponents). The further you get 0, the more roundoff error you will encounter with any floating point number.

Bottom line is... don't use "string" variables to store floating point values. Use "float" variables instead. Unless you want to use some of Strife's code to increase the precision, a "float" will be the best representation you can get with LSL.

- Ace

P.S. Note : this is not a limitation on LSL. It is inherent in ANY language which uses standard IEEE floating point representation.

1234567 in binary is 1 0010 1101 0110 1000 0111, leaving 3 more bits to represent the fractional value after the decimal point. Since 0.1234567 is less than 0.125 (.001, in binary), then yes, this particular case would get rounded to 1234567.0.

Decimal-to-binary conversion is more complex than "How many base-10 digits?" For example, the value 255 is 3 digits, which in binary is 1111 1111, 8 bits. 256, however, is still 3 digits, but in binary is 1 0000 0000, 9 bits. A single (unsigned) byte can't count any higher than 255, so it can only represent slightly over a quarter of 3-digit base-10 values. Therefore it would be misleading to say that a byte is limited to "3 digit" values, even though it is true that it certainly can't represent 4-or-more-digit values. (This is why hexadecimal is so popular for representing binary values, as it's a direct 1:4 ratio. 1 hex digit exactly correlates to 4 binary bits)

Fractional values are even more complicated. For example, 0.1 can't be exactly expressed in binary, since the binary equivalent is an infinitely repeating irrational value (much like 1/3 in decimal).

Oh absolutely. Floats are certainly capable of representing values much smaller than can be significantly cast to a string.

Quite a bit fewer, actually. Any float with an straight-ones exponent field is considered +/- infinity (if 0 mantissa) or not a number (if non-zero mantissa).

Thanks everybody for the insight...

Well, actually, 1/3 isn't irrational, because it can be expressed as a rational fraction. Repeating values aren't necessarily irrational unless they can't be expressed as a ratio of some kind. PI is irrational, for example. Sqrt(2.0) is also irrational.

As for 0.1 represented in binary, I don't think it is irrational, but it is a transcendental number that cannot be represented accurately within a limited number of significant digits.

Algebra was a long time ago.