Talk:PI

64 bits?

this has bugged me for some time... the value reported on this page for PI is a more precise value that can be held in a 32bit float (3.1415927), but considerably less than a 64bit float.... and leads me to wonder.... is float math being done in 64bits, then being rounded to 32bits? on a related note does anyone have a solid method for extracting the actual float value to text vs the truncation (that I thought was fixed) that happens on string casts? I know that vectors and rotations in a list are not as severely truncated when cast to string, but there still seems to be some rounding going on (looks like ~1 place with casts from lists, and 2 with casts directly.
-- Void ^{(talk|contribs)} 00:14, 27 October 2010 (UTC)

As to extracting the exact float value, what format do you want it in? Scientific, Hex, Memory, Encoded-Memory? -- Strife ^{(talk|contribs)} 15:20, 27 October 2010 (UTC)

actually I was thinking literal extended numeric value.... but I realized after the fact that I could just use your fui function and get the hex value of the integer... after that I just do the rest outside of lsl so I can get the extended value... I just need to take time to do that.... but even assuming the value is accurate to as many places as they claim, it's only incidentally so since other values won't be... LSL's lack of standardization makes me batty some times.
-- Void ^{(talk|contribs)} 05:44, 28 October 2010 (UTC)

While I admit it's been a while since I've tested the functions, I am willing to bet they still work as I intended when I wrote them, which is to say, perfectly. I wouldn't recommend them if I didn't trust them. You can use any of them to get every last bit out of the floating point value. When I last did testing I was unable to find a value that caused any of the functions problems. However if you want to check if LSL using doubles (which it's not), I recommend you use the (double) Safe version of Float2Hex. -- Strife ^{(talk|contribs)} 18:21, 29 October 2010 (UTC)