User talk:Strife Onizuka/Float Functions

From Second Life Wiki
Jump to navigation Jump to search

What's the purpose of llFloatCompare?

Hi, I'm a bit confused by llFloatCompare, why include fui, iuf and FloatCompare in a script when you can just do it this way:

<lsl> 

       float f_1 = 0.00000003;
       float f_2 = 0.00000002;
       if(llFabs(f_1) - llFabs(f_2) > 0 ) {
           llOwnerSay("f_1 > f_2");
           return;
       }
       if(llFabs(f_1 - f_2) == 0.0) {
           llOwnerSay("f_1 = f_2");
           return;
       }
       llOwnerSay("f_1 < f_2");

</lsl>

I have run a test in Second Life, using your FloatCompare function (because none of required functions even compile on OpenSim) and compared it to my method and the results are the same, even my simple method succeeds where your method fails. I used the following script:

<lsl> // [ bla bla bla ] // I've spared you the 40 lines of code and functions that your FloatCompare method requires.

default { 

   state_entry() {
       float f_1 = 0.999993;
       float f_2 = 0.999992;
       if(llFabs(f_1) - llFabs(f_2) > 0 ) {
           llOwnerSay("Kira: f_1 > f_2");
           jump strife;
       }
       if(llFabs(f_1 - f_2) == 0.0) {
           llOwnerSay("Kira: f_1 = f_2");
           jump strife;
       }
       llOwnerSay("Kira: f_1 < f_2");

@strife; 

       llOwnerSay("Strife: " + (string)FloatCompare(f_1, f_2, 1));
   }

} </lsl>

Test 1, Your method fails.

For <lsl> float f_1 = 0.9999993; float f_2 = 0.9999992; </lsl>

Output 

Object: Kira: f_1 > f_2
Object: Strife: 0

They are not equal... What is this?

Test 2, Your method fails.

For: <lsl> float f_1 = 0.9999003; float f_2 = 0.9999002; </lsl>

Output 

Object: Kira: f_1 > f_2
Object: Strife: 0

Still equal? WTH?

Test 3, We both succeed.

For: <lsl> float f_1 = 0.999993; float f_2 = 0.999992; </lsl>

Output 

Object: Kira: f_1 > f_2
Object: Strife: 1

Test 4, We both fail.

<lsl> float f_1 = 0.000000000000000000000000000000000000000000002; float f_2 = 0.000000000000000000000000000000000000000000001; </lsl>

Output 

Object: Kira: f_1 = f_2
Object: Strife: 0

Here are a few funny ones:

Test 5, My method works, your method just crashes with Math Error

<lsl> float f_1 = 3.402E+38; float f_2 = 3.403E+38; </lsl>

Output 

Object: Kira: f_1 < f_2
Object: Object [script:New Script] Script run-time error
Object: Math Error

This one too:

Test 6, My method works, your method just crashes with Math Error

<lsl> float f_1 = 3.403E+38; float f_2 = 3.402E+38; </lsl>

Output 

Object: Kira: f_1 > f_2
Object: Object [script:New Script] Script run-time error
Object: Math Error

Don't get me wrong, you provide no documentation on what those functions are doing (what they mean) so I don't know if I used them correctly...

  • Could you please clarify what they are supposed to do?
  • Why include this chunk of obfuscated garbage with magic numbers:

<lsl> integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe {//union float to integer 

   if((a)){//is it non zero?
       integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
       if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stirde of normalized range
           return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
       integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
       return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a - (3 <= (a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)))))))) << 23 ) | b);
   }//for grins, detect the sign on zero. it's not pretty but it works. the previous requires alot of unwinding to understand it.
   return ((string)a == (string)(-0.0)) << 31;

}

float iuf(integer a) {//union integer to float 

   return ((float)("0x1p"+(string)((a | !a) - 150))) * ((!!(a = (0xff & (a >> 23))) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));

}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warented.

integer FloatCompare(float a, float b, integer c) {//compare floats and allow for a margin of error, requires fui(). 

   if(a - b)//(c) Strife Onizuka 2006 
   {//they are not equal
       //First we convert the floats to integer form, as they would be in memory;
       integer a_i = fui(a);
       integer b_i = fui(b);
       integer a_e = (a_i >> 23) & 0xff;
       integer b_e = (b_i >> 23) & 0xff;
       if(!(a_e || b_e) || //to disable the +/- roll under support put a // just before the !
           ((a_i & 0x80000000) == (b_i & 0x80000000)))//sign match check
       {//start by getting and testing the difference, this is what limits c
           integer diff = a_e - b_e;//ugly is fast, basicly, it gets the mantissa, sets the sign on the mantisa,
           if(diff >= -1 || diff <= 1)//shifts it depending on exponent, finaly executes the test.
               if(llAbs(((((a_i & 0x7FFFFF) | (!!a_e << 23)) * ((a_i >> 31) | 1)) >> !~-diff) - 
                        ((((b_i & 0x7FFFFF) | (!!b_e << 23)) * ((b_i >> 31) | 1)) >> !~diff)) <= c)
                   jump out;
       }
       return (a > b) - (a < b);
   }
   @out;
   return 0;

} </lsl>

in every script when you can use the method above?

Your scripts seem to either give wrong answers, match mine or, in your case, they just crash...

Kira Komarov 06:12, 23 May 2012 (PDT)

FloatCompare is designed to tell you if two floats are close together. Closeness is not specified by some hardcoded constant but by the magnitude of the numbers. To do this we get the memory representation of the floats (as integers, it's what fui does). Then compare the mantissas and exponents. The integer parameter specifies the max difference between them.
As to magic numbers. Some are shared with Float2Hex and that has pretty good documentation. GTG -- Strife (talk|contribs) 11:50, 23 May 2012 (PDT)
Right. So where is "the magnitude of numbers" specified? To be more precise, if "closeness" is not specified by some hardcoded constant then how is it specified? Telling me what it is not specified by does not help because I can tell you what it is not specified by as well... For example, I am quite sure it's not specified by lederhosen... As it stands, aside from the crashes, it does not seem to do the job. Also, if you use integers to specify (this word has been abused so much, it should go on strike) the maximum difference (is this the "closeness" you mentioned?) between floats, then what is the point of it? I mean is there some mathematics involved or is it sort of an empirical measurement where some comparisons fail, some pass and some others crash?
I may take a look at Float2Hex later since that's another mystery but you suggested these functions for a project of mine (when I tried to explain determinism to you) and I guess it was a good choice not to use them. For example, you could take my 9-liner code and introduce another float which can give you the distance between those floats precisely (through elementary inequalities). I am not sure I follow your reasoning. In fact is there any reasoning at all? Are there any mathematical definitions that would explain what "closeness" means in your case?
Your girlfriend here tosses your functions to Linden as an example. However your functions fail the most basic tests (again, leaving aside the funny crashes) and are not explained at all. How do you expect Linden to take action on something that neither you, or her seem to fully comprehend let alone explain in detail?
She even cites your code with "//-- formating functions, please ignore", but how can you ignore that if it doesn't work properly. I don't even have to follow your obsessions on bit twiddling, I can just run the tests above and get undefined behavior (and that's putting it boldly because you just dump the function with no explanation, so I guess I don't know what the defined behavior is in the first place to be able to claim that it's undefined). Did you take this code from somewhere? Perhaps it had a point there...
Kira Komarov
Sorry didn't mean to get you riled with a short incomplete reply, I just ran out of time and didn't want to give you nothing. -- Strife (talk|contribs) 11:47, 24 May 2012 (PDT)
I know why fui was crashing. 3.403E+38; is getting rounded up to inf. When I wrote fui and iuf (3 or 4 years before Mono), infinity wasn't supported by LSL, its assumed that infinity and nan would crash the script, hence the comment at the end of iuf (the 0xff exponent is set aside for floating point magic numbers like nan and infinity).
I wrote the function in the course of examining floating point arithmetic drift. That is to say the steady corruption of the lowest bits due to arithmetic operations. The problem is corruption manifests itself in the values of the bits in the mantissa of the float, it can even result in the exponent being increased.
I feel I need to explain how floats work so lets take a moment to go over that. However it's easier for me to provide code that replicates how it works than to put how it works into words.
A float is made of three parts. This is how it is stored in memory. All operators take it in this for, perform their operation and return a value in this form. A float is just a collection of bits that have meaning given a specific context.
  1. sign - 1 bit
  2. exponent - 8 bits (unsigned)
  3. mantissa - 23 bits (unsigned)
The value of a float is calculated as follows:

<lsl>float value(integer sign, integer exponent, integer mantissa){ 

   //make the sign 1 or -1, zero maps to 1
   sign = 1 | -!!sign;
   
   //For the sake of simplicity we will ignore NaN and Infinity values.
   
   //normalized range
   if(exponent)
        return sign * (0x800000 + mantissa) * llPow(2.0, exponent - 150);

   //denormalized range
   return sign * mantissa * llPow(2.0, -149);

}</lsl>

Now LSL is not C, in C you can take a float, do some hand waving and presto you can read the float value as if it were an integer value. That is to say, given the memory location of the float, read that location as if it were an integer. Since LSL does not let you do this (though there is nothing stopping you from doing this in LSO), I wrote a set of functions to approximate this. This is what FUI and IUF do (their only flaw is not properly handling nan and infinity). I wrote these functions of an LSL based LSO interpreter that I never finished. They are an evolutionary dead end a solution without a problem to solve.
The problem is that as you perform certain arithmetic operations you get drift. The lowest bits of the mantissa do not match up with the math. That is to say, the way we as humans evaluate the operations is slightly different than the way the computer does. Take for example (1.0 / 10) * 10. As humans we would say that it is equal to 1. The computer on the other hand will say it's not equal to 1. This is because the result of (1.0 / 10) is an approximation, the precise value would a different way of storing the value.
What this function does is let you compare the mantissa of the two floats. In it's most basic form it's ((mantissa_a - mantissa_b) > c) (this simplification doesn't take into consideration that the exponents won't match, or that the sign of the return is based on the larger value).
Lets look at the following function (I just wrote this and haven't had time to test it):

<lsl>integer FloatDistance(float a, float b, integer distance){ 

   //If you want to treat -0 and 0 as the same number replace "-~" with "+"
   integer A = fui(a);
   integer B = fui(b);
   if((A ^ B) & 0x80000000)
       A = (A & 0x7fFfFfFf)-~(B & 0x7fFfFfFf);
   else
       A = llAbs(B - A);
   //distance is treated as if it were unsigned. If you do not want this, remove both " - 0x80000000"
   return (A - 0x80000000) <= (distance - 0x80000000);

}</lsl>

It works on the idea of measuring the distance between two floats by looking at how many values lie between them. I'm not sure why I chose to use the formulation I did in FloatCompare and not this, the difference is that the above formulation weights changes in exponent very differently. FloatCompare treats changes is exponent very seriously it really screws with the distance, FloatDistance pays no special attention to it. Reguardless, most arithmetic corruption you notice by the time you test for it trashes more than one bit, so really you want to give it a distance of atleast 3, 7, or maybe even 15. I did contemplate allowing the user to specify the number of trashed bits instead of a distance but decided that was too narrow minded.
These functions exist in my userspace instead of in an article because they are from a certain perspective, abandon-ware, I never really intended anyone else to use them. Not all of this code was written because it was a good idea, some of it was written because I was curious if I could, sometimes to find out just how bad an idea it was. You use them at your own risk. They aren't documented particularly well, they aren't even LSLEditor Safe. Hell they even had letter variables instead of proper names. Maybe I should add a disclaimer about the close proximity of dragons? This code was written during an optimization phase or mine (the tightness in the source is due to the 16KiB memory constraint of LSO).
You complain about the code (with reason) and you accuse me of plagiarism but I'm actually a bit flattered that you would give the function a whirl. Despite your contempt and loathing for me, you still tried to use the code. Honestly I've never seen code like it, I didn't plagiarize it. There is no reason for anyone in the real world to have written anything like it, it required a contrived situation where you can't just union{ float f; int i; } or do a pointer typecasting. The whole concept of implementing a function to do this is a terribly bad idea. The creation of this function required two things: my willingness to write this insane function and my unwillingness to just submit a patch to LL to add this to the LSL compiler (LSO keeps no type meta-data in for the stack so you can pop an integer as a float and vice versa). The optimization was for fun.
But again, thanks for showing interest in it. It was some of my favorite code to write. It was a challenge. I'll think about how to best add infinity and nan support to them. -- Strife (talk|contribs) 23:14, 24 May 2012 (PDT)
No, I'm not accusing you. I was curious what would happen if somebody would take you seriously and use this in a build (and I'm pretty sure plenty take you seriously given how much gas you blow). It never really crossed my mind to use your code in my projects (I make it policy to not include code that has magic numbers even if it means making my scripts less "efficient") and I have never really traced it to see what exactly you are doing. Obscurity to me means very little - it's only part of the job to create something and the hardest part is to show people what you mean with it. I did however see you toss this code at Linden and ask why something else does not work which relies on it. So, I was really curious what others around me are doing... I was a bit surprised... And I guess that having goons jump at you, is a good reason for anybody not to contribute and invest their talent in something other than the Second Life wiki.
If you look my articles you can still see that I must justify each part of my code and pulling of tricks like telling people what it does not relate to instead of offering the formalities behind it never accomplishes anything - well, I guess you could get a gang together and file Jira reports based on some false sense of vanity and prestige. I mean at this rate, at least I know what I can answer when somebody asks me "why do I have lag?" / "why doesn't stuff work in SL?" etc...
Don't get me too wrong on the loathing, you started a thread with, let's be fair and quote so you don't get the false impression that I am making stuff up:
"Wiki: Deny all content deletion requests made by Kira Komarov and restore all content"
Which is a sign of disrespect... I am unsure whether that disrespect is aimed at me, at my work or at yourself. Quite frankly, I do not mind if you delete your functions because they do not work, you are busy "with work" as you posted on my talk page or for whatever other reason - they are yours, just because you barfed them here, will not make me trod into them like an elephant and rip them apart or, like Void SInger copy them and redistribute them "just to annoy you". However, I did not expect you to violate your integrity to go that far into ... peasantry to create a Jira (which, as I've seen countless collaborative bug-systems) are really just meant for bug reports and "serious" issues. I hope that satisfies your statement and you can see that I do not really "hate" you...
The problem with people like you is that you are 90% mouth and 10% essence - I just wanted a confirmation. I mean, your self-respect is so low that you open up such a thread when most of your scripts are broken. I wouldn't have minded that somebody with lots of contributions would have requested from me not to remove my own content, or had a chat with me about some bug they have noticed. However, that a person like you drives and Internet form/wiki war, is more sad than it is comprehensible.
You like the wiki (I like it too) and you want it to be used in collaborative environments, but how could I collaborate with you under such circumstances? Should I back you up and we fight together, senseless wars, against people contributing to this wiki? I tell you what, if together we team up, I promise you that in about one week we will have Linden dangling by their noses and we will thwart off any contribution to this wiki. I'm sorry, but that's not my sense of fun...
On the other hand, I think that I have met you in-world on an alt. I'm not sure if it was you or not (I personally use my main avatar from everything from sex to conferences, not because it's smart, but because I really do not care <-- try this sentence) because we discussed some intricate coding issues with Quick Collar. If that was really your alt, you should know by now that I am actually very collaborative, open and if it's not the funny articles also fun and easy to get along with.
That being said, I really wanted to see what you're made of. I mean, I am very aware and I have seen some people in other environments that have truly amazing skills and knowledge and who not only surpass mine but they are so good they make me blush. However, I see now that when you wage war against a person like me, your words come easy... When, instead you are attacked and held responsible you cower inside yourself. It's a pity really, having had that "covert" meeting we had, I think we could have even got along finely...
I still cannot understand why you would create a a Jira for that when, in essence, it has nothing to do with you...
Kira Komarov 12:07, 25 May 2012 (PDT)

P.S.

Thank you for explaining. But spare your energy and post what you have explained to me right here where you advertise your function. It's actually a very good explanation.

... Don't feed it to me though, thanks. I can handle it myself.

Kira Komarov 12:15, 25 May 2012 (PDT)

Ever considered making a fui16?

I was just looking around for how I could union a float into a 16 bit integer, perhaps using the IEEE 754-2008 half-precision format. Yes, I know there would be losses, and I also know that SL olny has 32 bit integers. The final goal for my application is to pack two floats into a single integer, via bitshifting the first into the high range and then ORing with the second, a la: <lsl> // To pack: float a = PI; float b = 4.2; integer result = (fui16(a) << 0x10) | fui16(b);

// To unpack: float c = i16uf(result >> 0x10); // Might need to perform some further magic here to account for the fact that the sign bit doesn't shift. float d = i16uf(result & 0xFFFF); </lsl> Of course, in the general case one can't make assumptions about range and resolution. That said, in my application I can make such assumptions, and I'm just going to hack together something that works based on those assumptions. I'm just here feeding the fetish that resulted in these very-useful-to-me functions (fui, iuf) in the first place. >:D

—The preceding unsigned comment was added by Cron Stardust

Lets see, I could either work on Template:LSL Function et al as to split the notes section in half, or I could write fui16 a most clever function. Hmmm. Fun clever coding or Template drudge. Half precision doesn't have the same range, grrrr... -- Strife (talk|contribs) 20:57, 24 December 2012 (PST)
Upon second though, I really don't want to dig into floating point math at the moment. Mostly you just need to add clipping to fui, change the constants and add infinity support to iuf. With clipping implemented the error correcting code can be removed. Here is my first crack at updating the constants. I've not tested it. -- Strife (talk|contribs) 21:35, 24 December 2012 (PST)

<lsl> integer fui16(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe {//union half-precision float to short integer 

   if((a)){//is it non zero?
       integer b = (integer)(a < 0) << 15;//the sign, but later this variable is reused to store the shift
       if((a = llFabs(a)) < 0.0001220703125)//Denormalized range check & last stride of normalized range
           return b | (integer)(a * 16777216.0);//the math overlaps; saves cpu time.
       if(a > 65504.0)//Round up to infinity
           return b | 0x7C00;//Positive or negative infinity
       integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 14;//extremes will error towards extremes. following yuch corrects it.
       return (0x3FF & (integer)(a * (0x800 >> b))) | (((c + (b = (integer)(a *= (0.0000152587890625 * (0x40000000 >> c))))) << 10 ) | b);
   }//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
   return (integer)((string)a == (string)(-0.0)) << 15;

}

float i16uf(integer a) {//union short integer to half-precision float 

   if((a & 0x7C00) == 0x7C00)
       return (1 | ((a << 16) >> 31)) * (float)"Infinity";
   return 0.000000059604644775390625 * (1 << (a - !!a)) * ((!!(a = (0x1f & (a >> 10))) << 10) | ((a & 0x3ff))) * (1 | ((a << 16) >> 31));

} </lsl>

<lsl> // To pack: float a = PI; float b = 4.2; integer result = (fui16(a) << 16) | fui16(b);

// To unpack: float c = i16uf(result >> 16); // No magic needed, sign bit is handled correctly. float d = i16uf(result); </lsl>

Just tested in SL with the following results: Had to place a closing paren in the first return statement of iuf16, I placed it just before the mult as I suspect that's what was intended. I wrote a simple ownersay of the existing test code which gave the following as the output: Cron Stardust 16:12, 25 December 2012 (PST)

<lsl> 

 a = 3.141593 = 0xC90FDBp-22

= c = 3.140625 = 0xC9p-6 

 b = 4.200000 = 0x433333p-20

= d = 4.199219 = 0x433p-8</lsl>

Further testing, looking for error cases, resulted in a lot of good: the functions seem to operate as they should. I tested using all the constants demonstrated on the Wikipedia article and only one failed to match perfectly: 0.0000000596046 doesn't encode to 0x0001, instead it results in 0x0000. All other values seem to work great. Cron Stardust 22:00, 25 December 2012 (PST)
Also tested that with a = -2.0 and b = -2.0 that everything works out: no issues happen with the sign bit status that I could detect - so I took the liberty of changing the comment in your code. Cron Stardust 22:34, 25 December 2012 (PST)
I'm willing to bet it's a lack of precision in their approximation. Try: 0.000000059604644775390625 -- Strife (talk|contribs) 00:36, 26 December 2012 (PST)
I'm not 100% sure of the "llFloor((llLog(a) / 0.6931471...)" line but I think in this range it's accurate and we don't need to do any correction. The only way to know for sure is to try every value in the range [0.0001220703125, 65504.0]. I know it's not going to overflow so I've removed the overflow protection code. If you want to do that testing, here is the return line you would use which assumes that "c" is accurate: return (0x3FF & (integer)((a / (float)("0x.004p"+(string)c)))) | (((c + 15) << 10 ) | b); It has the added bonus of making fui16 LSLEditor safe. This was also a good demonstration of how the layers of correction code were bolted on. -- Strife (talk|contribs) 00:50, 26 December 2012 (PST)

This is a better version of what I was talking about but it needs extensive testing. If c is not accurate this will not work. <lsl> integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 15;//extremes will error towards extremes. No corrections are attempted. return (0x3FF & (integer)((a * 0.03125 * (0x40000000 >> c)))) | ((c << 10) | b); </lsl> I've gone back and removed my string-float pow code since it can all be done with integers and float math. Faster this way. Less stressful for the sim. -- Strife (talk|contribs) 01:32, 26 December 2012 (PST)

Testing

Just run the following code and it will tell you if c is accurate for the entire half-precision range (this is one of the things iuf is really good for, iterating over every float value). -- Strife (talk|contribs) 02:55, 26 December 2012 (PST) <lsl> integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe {//union float to integer 

   if((a)){//is it non zero?
       integer b = (a < 0) << 31;//the sign, but later this variable is reused to store the shift
       if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
           return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
       integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
       return (0x7FFFFF & (integer)(a * (0x1000000 >> b))) | (((c + 126 + (b = ((integer)a - (3 <= (a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)))))))) << 23 ) | b);
   }//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
   return ((string)a == (string)(-0.0)) << 31;

}

float iuf(integer a) {//union integer to float 

   return ((float)("0x1p"+(string)((a | !a) - 150))) * ((!!(a = (0xff & (a >> 23))) << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));

}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.

integer test(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe {//union half-precision float to short integer 

   if((a)){//is it non zero?
       if((a = llFabs(a)) < 0.0001220703125)//Denormalized range check & last stride of normalized range
           return FALSE;//the math overlaps; saves cpu time.
       if(a > 65504.0)//Round up to infinity
           return FALSE;//Positive or negative infinity
       integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818)) + 14;//extremes will error towards extremes. following yuch corrects it.
       return (integer)(a *= (0.0000152587890625 * (0x40000000 >> c))) - 1;
   }//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
   return FALSE;

}

float i16uf(integer a) {//union short integer to half-precision float 

   if((a & 0x7C00) == 0x7C00)
       return (1 | ((a << 16) >> 31)) * (float)"Infinity";
   return 0.000000059604644775390625 * (1 << (a - !!a)) * ((!!(a = (0x1f & (a >> 10))) << 10) | ((a & 0x3ff))) * (1 | ((a << 16) >> 31));

}

list gBadBlockCounts;

default { 

   state_entry()
   {
       llOwnerSay("beginning test");llResetTime();
       
       integer badCount = 0;
       integer badStart;
       
       integer start = fui(i16uf(1) / 2.0);//start just before min value, these will get clipped to zero.
       integer end = fui(65536.0);//stop just after infinity
       integer i;
       for(i = start;i < end; i++)
           if(test(iuf(i)))
           {
               llSetText("bad:  "+(string)i, <1.0, 0.0, 0.0>, 1.0);
               if (badCount++ <= 0)
               {
                   badStart = i;
                   llOwnerSay("Found bad number: " + (string) i);
               }
           }
           else
           {
               llSetText("good: "+(string)i, <0.0, 1.0, 0.0>, 1.0);
               if (badCount > 0)
               {
                   llOwnerSay("Total of " + (string) badCount + " numbers, ending with " + (string) (i-1));
                   gBadBlockCounts = [badStart, i - 1] + gBadBlockCounts;
                   badCount = 0;
               }
           }
       llSetText("test complete.\ntook " + (string) llGetTime() + " secs over " + (string) (end - start) + " values\nsaw " + (string) llGetListLength(gBadBlockCounts) + " bad blocks.\nTouch for list of bad.", <0.0, 1.0, 1.0>, 1.0);
       state printout;
   }

}

state printout { 

   touch_end(integer index)
   {
       while (--index >= 0)
       {
           if (llGetListLength(gBadBlockCounts))
           {
               llRegionSayTo(llDetectedKey(index), 0,
                   "Bad blocks strided list, using stride pattern (block_start, block_end):"
               );
               llRegionSayTo(llDetectedKey(index), 0,
                   llDumpList2String(gBadBlockCounts, ", ")
               );
           }
           else
           {
               llRegionSayTo(llDetectedKey(index), 0,
                   "Nothing to report."
               );
           }
       }
   }

} </lsl>

Tested this morning. Went bad at values 864026624 through 900508790. Not sure if there were further values: I set it up to run and then wen to work for the day, when I came back it had been yelling for a very long time... :P Will see what I can do, however while I can understand the code, I've not yet been able to get my mind in deep enough to understand the algorithm. Cron Stardust 18:55, 26 December 2012 (PST) EDIT: Just noticed that there was a function named test in there that wasn't used: I'd pasted in the fui16 function from above to make the code compile and run. That may have invalidated the test, so I've going to retest usung the "test" function in place of the fui16 call in state_entry. I've edited the above state_entry to reflect my current code.
Just passed the 864026624 mark without errors, so yes: my previous test was invalid. Continuing testing - just like GLaDOS likes. Cron Stardust 20:59, 26 December 2012 (PST)
I should have thought of this sooner, we don't need to test every value, just the ones who's values surround where the value of "c" changes. We only need to test ummm 84 values... just the powers of two and the immediate lesser values. -- Strife (talk|contribs) 01:44, 27 December 2012 (PST)

<lsl> integer fui(float a)//Mono Safe, LSO Safe, Doubles Unsupported, LSLEditor Unsafe {//union float to integer 

   if((a)){//is it non zero?
       integer b = (integer)(a < 0) << 31;//the sign, but later this variable is reused to store the shift
       if((a = llFabs(a)) < 2.3509887016445750159374730744445e-38)//Denormalized range check & last stride of normalized range
           return b | (integer)(a / 1.4012984643248170709237295832899e-45);//the math overlaps; saves cpu time.
       integer c = llFloor((llLog(a) / 0.69314718055994530941723212145818));//extremes will error towards extremes. following yuch corrects it.
       a /= (float)("0x1p"+(string)(c -= ((c >> 31) | 1)));
       integer bb = ((integer)a - (3 <= a));
       return (0x7FFFFF & (integer)(a * (0x1000000 >> bb))) | (((c + 126 + bb) << 23 ) | b);
   }//for grins, detect the sign on zero. it's not pretty but it works. the previous requires a lot of unwinding to understand it.
   return (integer)((string)a == (string)(-0.0)) << 31;

}

float iuf(integer a) {//union integer to float 

   integer aa = 0xff & (a >> 23);
   return ((float)("0x1p"+(string)((aa | !aa) - 150))) * ((!!aa << 23) | ((a & 0x7fffff))) * (1 | (a >> 31));

}//will crash if the raw exponent == 0xff; reason for crash deviates from float standard; though a crash is warranted.

integer get_log2(float a){//we use the natural log because testing showed it's more accurate than log10. 

   return llFloor((llLog(a) / 0.69314718055994530941723212145818));//must be divide, multiplying the reciprocal adds extra corruption.

}

integer test_log2(integer power) { 

   float a = (float)("0x1p"+(string)power);
   float b = iuf(fui(a) - 1);//The underflow is in our favor and does what we want.
   integer c = get_log2(a);
   integer d = get_log2(b);
   integer e = (c == power) && ((d + 1) == power);

// llOwnerSay(llList2CSV([power, c, d, Float2Hex(a), Float2Hex(b), int2hexdword(fui(a)), int2hexdword(fui(b)), e])); 

   return e;

}

default{ 

   state_entry(){
       integer start = -25;
       integer end = 17;
       integer i;
       for(i = start; i <= end; i++)
           if(!test_log2(i))
               llOwnerSay((string)i);
   }

} </lsl>

Ok, so executed - though I'm leaving the other script running, and it seems good thus far; will report when it completes. The results from this new test are that I saw values reported in the following ranges: [-25, -16], -14, [-12, -2], [3, 17] -- Cron Stardust 19:14, 27 December 2012 (PST)

fui support for NaN and Inf

I must be one of the few people who have found an actual use to fui :) I'm using it for compact lossless transmission of floats over HTTP to a PHP server in base 64 (after removing the == and the trailing A's), and I decode it in the server using unpack() and some string manipulation. I would love to see fui support NaN, Inf and -Inf, but more for the sake of completion than because I have a real use (except possibly debugging). Maybe it's as straightforward as adding this on top? <lsl> 

 if ((string)a == "Infinity") return 0x7F800000;
 if ((string)a == "-Infinity") return 0xFF800000;
 if ((string)a == "NaN") return 0x7FC00000; // to choose one

</lsl> I guess there's no way to extract the actual bits of a NaN, or is there? --Pedro Oval 05:09, 26 December 2012 (PST)

Oops, I've corrected "Inf" to read "Infinity" above. --Pedro Oval 07:58, 26 December 2012 (PST)

Sure, I don't see why not. I'll think about ways of doing it (I'm not sure if successive tests is really the best way of doing so). The reason Infinity was never handled was that LSO doesn't allow it. These functions were originally conceived before Mono was on the horizon (at the time I had wanted to build an LSO bytecode emulator in LSL). -- Strife (talk|contribs) 01:01, 27 December 2012 (PST)
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User_talk:Strife_Onizuka/Float_Functions&oldid=1175665"