KT Kingsley Posted April 12, 2020 Share Posted April 12, 2020 default { touch_end (integer count) { llOwnerSay ((string) llFrand ((float) −2147483648)); llOwnerSay ((string) llFrand (−2147483648.0)); } } What's happening here? llFrand ((float) −2147483648)) always generates a negative value, while llFrand (−2147483648.0) always returns a positive one. (That's "always" as in "as many times as I've bothered to click the object".) Link to comment Share on other sites More sharing options...
sandi Mexicola Posted April 12, 2020 Share Posted April 12, 2020 (edited) I do not know exactly what the problem is, but I would avoid using the smallest possible integer. It is interesting that using −2147483647 and −2147483647.0 instead both generate positive values. Edited April 12, 2020 by sandi Mexicola 1 Link to comment Share on other sites More sharing options...
sandi Mexicola Posted April 12, 2020 Share Posted April 12, 2020 (edited) Also, according to the LSL documentation: "Many integers outside the range [-2^24, +2^24] can not be represented in a float (this is an inherent limitation of the float type)". http://wiki.secondlife.com/wiki/LlFrand Well, 2^24 is only 16777220, much smaller than the numbers you are using. Edited April 12, 2020 by sandi Mexicola 1 Link to comment Share on other sites More sharing options...
Mollymews Posted April 12, 2020 Share Posted April 12, 2020 is not a specific LSL issue. Is the way IEEE 754 floating point arithmetic resolves overflow and how this is handled/interpreted in CIL languages −2147483648.0 returns positive (float) −2147483648 returns negative some LSL code which explores this default { state_entry() { float f = −2147483648.0; float g = 2147483648.0; llOwnerSay("1st: " + llList2String(["FALSE", "TRUE"], (integer)(f == g)) + " " + llDumpList2String([f < 0.0, g < 0.0], " ")); f = (float) −2147483648; g = -2147483648.0; llOwnerSay("2nd: " + llList2String(["FALSE", "TRUE"], (integer)(f == g)) + " " + llDumpList2String([f < 0.0, g < 0.0], " ")); f = (float) 2147483648; g = -2147483648.0; llOwnerSay("3rd: " + llList2String(["FALSE", "TRUE"], (integer)(f == g)) + " " + llDumpList2String([f < 0.0, g < 0.0], " ")); f = (float) 2147483648; g = (float) -2147483648; llOwnerSay("4th: " + llList2String(["FALSE", "TRUE"], (integer)(f == g)) + " " + llDumpList2String([f < 0.0, g < 0.0], " ")); } } 1 Link to comment Share on other sites More sharing options...
Nova Convair Posted April 12, 2020 Share Posted April 12, 2020 (edited) You can not convert an integer to a float 100% exact. It will work with many numbers but not all. There will be rounding errors because you have either not enough precision or you even need infinite precision for several numbers. what is -2147483648 minus 1? it's +2147483647 of course 😎 - it's integer math on a real computer system So a rounding error of a single bit in the range of min-integer / max-integer can easily flip between that two You need to use -2147483647.9 - maybe! - I don't know how many bits the float mantisse in SL has - I noticed the floats have a pretty low precision. Edited April 12, 2020 by Nova Convair 1 1 Link to comment Share on other sites More sharing options...
KT Kingsley Posted April 12, 2020 Author Share Posted April 12, 2020 Thanks, everyone. I think I've got the gist of this now. Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now