INFINITY constant
Chaser Zaks
Very simple request, a infinity constant.
"INFINITY" { count(); yylval.fval = INFINITY; return(FP_CONSTANT); }
Support for negative infinity is implied by doing
-INFINITY
Log In
Bleuhazenfurfle Resident
Or, some basic level of "constant folding" (optimisation). If (float)"inf" was constant folded into a literal Infinity during compile, this wouldn't be necessary (though, that's still an ugly way to do it).
Would also like to see an NEG_INFINITY, because it's simply better than having to negate a positive infinity at run time, and code size. (Unless, again, that same basic optimisation is implemented.)
Would also also, like to see NaNs get the same treatment, in either case. Poor things get no love at all in LSL.
Chaser Zaks
Bleuhazenfurfle Resident In theory, doing
-INFINITY
would be the same as NEG_INFINITY
because constants are referred to just number. However NEG_INFINITY
might be more clear.Bleuhazenfurfle Resident
Chaser Zaks: "In theory", indeed. Last I heard in LSL, -42 was compiled as neg(42) — ie. the negation operator, applied to a positive literal.
If someone has evidence to suggest that has changed at some point, I'd be more than happy to be corrected. In the meantime, there's even less reason for -INFINITY to be any better.
I do strongly agree that ±INFINITY is, however, a vast improvement over
(float)"±inf"
and friends; casting a string is relatively horrendous from both a clarity and efficiency perspective.And as someone who often uses the Infinities as a sentinel value, I approve of this post.
Lucia Nightfire
Does (float)"inf" and (float)"-inf" not work?
Chaser Zaks
Lucia Nightfire It does, but that comes at the cost of having to convert a string to a float.
.locals init (float32)
ldc.r8 (00 00 00 00 00 00 f0 7f)
stloc.s 0
vs
.locals init (float32)
ldstr "inf"
call float32 [LslLibrary]LindenLab.SecondLife.LslRunTime::StringToFloat(string)
stloc.s 0