Bug - Not A Bug Odd results for float to string

Bale

Bale

Minion
r11042. Thanks Jason. That did fix the problem you were aiming at. Unfortunately...

Code: 
> ash float a = 1.2; to_string(a);

Returned: 1.2000000476837158

> ash float a = 1.3; to_string(a);

Returned: 1.2999999523162842

> ash float a = 1.00; to_string(a);

Returned: 1.0

Perhaps the oddest thing is that 1.0 becomes 1.0
 
Last edited:
jasonharper

jasonharper

Developer
Not a bug; there is no such thing as a float with a value that is exactly 1.2 or 1.3.

There are an infinite quantity of numbers within the range that a float can represent, yet only a finite quantity (4 billion or so) of float values. The fact that you can find ANY exact float values is a miracle, since the odds against it are infinite.

The gory details about how floats work can be found at http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html if anyone really wants to know.
 
Bale

Bale

Minion
Gotcha. I'm not really surprised by the response.

Perhaps we simply need a zlib function to round off a float as a string.

Edit: Ah, it seems that discussion is already going on in the zlib thread! :)
 
Last edited:
R

rlbond86

Member
I'd just like to add that this isn't a bug per se, but the behavior seems to have changed sometime in the last week or so. Thus, for example, the zlib function rnum is now broken. I agree with veracity, we need some sort of format specifier. Personally I am a fan of sprintf-like format specifiers, which is supported in Java by String.format().
 
roippi

roippi

Developer
rlbond86 said:
I'd just like to add that this isn't a bug per se, but the behavior seems to have changed sometime in the last week or so. Thus, for example, the zlib function rnum is now broken. I agree with veracity, we need some sort of format specifier. Personally I am a fan of sprintf-like format specifiers, which is supported in Java by String.format().
Click to expand...

You should probably check out r11055 then
 
You must log in or register to reply here.
Top