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)
- In LSO,
!=was strcmp. I tried to get them to keep it the same in Mono but they wouldn't. - As to validation:
- We set the bar pretty low for validation. To just test the beginning of the string. LSL as you already know stops parsing a float and returns what it currently has when it encounters a bad character. So basically we set validation to: Is LSL going to find something or nothing? Also LSL is not sensitive to leading spaces, at least not for spaces. This validator is really fast.
- Say you want to validate more carefully, ok, down the rabbit hole we go. We assume you do not want left over characters, does that include leading and trailing whitespace?
- Writing a complete validator for LSL would be difficult but not impossible, especially now. You could use JSON to do the number parsing for decimal floats, but you would still need to write a parser for hexfloats. That is the advantage of the current validator, it's format agnostic and fast. Having to test all characters is not fast, it's going to be quite slow.
- That said I've had a few ideas on how to do it faster (but still not fast). -- Strife (talk|contribs) 11:04, 19 December 2013 (PST)
- Sure, sensible validation of a float string is tricky, but I just think the current offering is pointless. People's eyes will light up when they see a proposed solution on the Wiki, and then be lifted to the heavens as they realise it does next to nothing :) Omei Qunhua 14:03, 19 December 2013 (PST)