Category talk:LSL Float
Something Seems Off
Simple Script <lsl> default {
state_entry()
{
llOwnerSay((string)((float)"3.402823466E+38"));
}
} </lsl> In Mono It Says: 340282300000000000000000000000000000000.000000
In LSL Is Says: 340282346638528859811704183484516925440.000000
Shouldn't Both Give The Same? Adi 20:51, 15 July 2009 (UTC)
- You can report it as a bug on Jira. The two values are however identical when read as floats. It's a feature of floating point precision types; the precision is at the top, not the bottom of the value. -- Strife (talk|contribs) 20:30, 17 July 2009 (UTC)
- I believe some inconsistency is to be expected, though the difference does seem a little odd. In any event Mono's floats are definitely different as they support infinity where LSO will throw a Math Error beyond the maximum or minimum values, the differences in general are a good thing and it's unlikely it cause any real faults between LSO and Mono scripts. I would definitely report it on the JIRA though, and maybe add the issue to Kelly Linden's Scripting Triage so it can investigated to find out if it's a true float error, or if it's a bug in the way Mono casts it back to a string (perhaps it's rounding by significant figures rather than decimal places, or intentionally removing "error"?), is worth investigating further at least.
-- Haravikk (talk|contribs) 10:16, 23 October 2010 (UTC)
- I believe some inconsistency is to be expected, though the difference does seem a little odd. In any event Mono's floats are definitely different as they support infinity where LSO will throw a Math Error beyond the maximum or minimum values, the differences in general are a good thing and it's unlikely it cause any real faults between LSO and Mono scripts. I would definitely report it on the JIRA though, and maybe add the issue to Kelly Linden's Scripting Triage so it can investigated to find out if it's a true float error, or if it's a bug in the way Mono casts it back to a string (perhaps it's rounding by significant figures rather than decimal places, or intentionally removing "error"?), is worth investigating further at least.
inf/nan handling in MONO
Last I checked both of those will crash a MONO script when used in math, just not on evaluation. I'll try and remember to confirm that. and see what they do when fed to a few functions.... might give me an excuse to reopen that jira Joshua nuked =S
-- Void (talk|contribs) 16:42, 30 May 2012 (PDT)
- I only know about it because 3.403E+38 gets rounded up to infinity in Mono (it came up in a discussion recently). I thought I should document the situation. I'm pretty sure *nothing* supports it but I'm looking forward to finding a clever way to do so with FUI. -- Strife (talk|contribs) 21:04, 30 May 2012 (PDT)
nevermind, looks like the change was either reverted or I got it wrong.... and the functions I tested that took float/vector seem to treat them as 0, although I do note that color actually saves the actual value. Like you, I actually wanted them to print the extended signaling. although i wanted it for crushing keys into rotation data types, and storage of integers into float parameters.
-- Void (talk|contribs) 20:30, 3 June 2012 (PDT)
Validation of float strings
The first example of a validation function:-
integer isValidFloat(string s) { return (string)((float)s) != (string)((float)("-" + llStringTrim(s, STRING_TRIM_HEAD))); }
seems to be very limited, in that the process examines the leading float-compatible characters only. Hence a string such as 1w2x3y will be treated as a valid float. I've yet to check the second validation example.
Secondly, be aware that under LSO, ( "abc" != "def") returns -1, whereas under Mono it returns 1. So the function result can't be tested for TRUE. Omei Qunhua 03:52, 19 December 2013 (PST)