lsl math tips on integer range

[Bridgette Puddles]

ok so I'm tracking a set of 8 ranges and I don't want code a mile-long script to check a range on an integer the basic idea I'm hoping to do is something like this

(Item_A < 0 || Item_A > 100) keeping them above -1 and below 101

But everything I have tried comes back as way out of range or stack heap.  Does anyone have any tips on this end?

[Wulfie Reanimator]

Your check is written as "less than 0 or greater than 100."
What you want (above -1 and below 101) would be:

(Item_A > -1 && Item_A < 101)

Or in a more mathy format, as in: 0 ≤ item ≤ 100

(0 <= Item_A && Item_A <= 100)

[Bridgette Puddles]

Thank you Wulfie after posting my 1st one it hit me like a ton of prims lol.

 

integer Range(integer value)
{
    integer Is_Range = value;
    if(value < 0) Is_Range = 0;
    else if (value > 100) Is_Range = 100;
    return value;
}

 

[Quistess Alpha]

If you want to be really esoteric, since your lower bound is 0, you can do:

x = (x>0)*x;

to make x 0 if it is negative, and

x = (x<=100)*x + 100*(x>100);

to keep it less than or equal to 100.

for the least legibility:

//x = (x>l)*((x<u)*(x-u)+(u-l))+l; // if(x<l) x=l; if(x>u) x=u;
x = (x>0)*((x<100)*(x-100)+(100));

 

[Bridgette Puddles]

of the two "mine and yours" what would you think would be less work on the server end, trying to keep the load low on my scripts?

[Quistess Alpha]

2 minutes ago, Bridgette Puddles said:

what would you think would be less work on the server end, trying to keep the load low on my scripts?

the branchless one-liner, is probably "best" on server performance, but the difference is undetectable, and legibility is often more important than efficiency.

[Bridgette Puddles]

thanks, I will try both and see which one works best on that end.

[Bleuhazenfurfle]

19 hours ago, Quistess Alpha said:

the branchless one-liner, is probably "best" on server performance, but the difference is undetectable, and legibility is often more important than efficiency.

In compiled code, the branchless version absolutely wins out due to pipelining and cache coherancy benefits — in an expression that simple, the variable is read into the processor just once, and you get the math ops basically overlapping each other, with a write of the final result at the end.

Though LSL shows no sign of being optimised or even just JIT'd, so with VM overheads, I doubt any of that matters.  I wouldn't be at all surprised if the fewer variable references of the branch version wins out.

Never cared enough to actually try and measure it, though.  Difference will be way down in the noise…  Write it so you can still read it in 6 months time.

[Frionil Fang]

On 8/2/2023 at 5:23 PM, Quistess Alpha said:

the branchless one-liner, is probably "best" on server performance, but the difference is undetectable, and legibility is often more important than efficiency.

I got curious since my attempts to inline some performance-critical branches have had little effect in the past and had to do some barebones timing. Not super scientifically rigorous.

1 million ops per batch, 12 batches, drop best and worst batch, convert to operations per second.

Script:

Quote

default
{
    state_entry()
    {
        integer v;
        integer a = 0; // lower bound
        integer b = 100; // upper bound
        integer diff = b-a; // for inline ver
        integer i;
        llResetTime();
        for(; i<1000000; ++i) {
            v = (integer)llFrand(300)-100; // comment to use v = 0
            v = (v>a)*((v<b)*(v-b)+diff)+a; // inline math
            //if(v<a) v = a; else if(v>b) v = b; // branch
        }
        llOwnerSay((string)llGetTime());
    }
}

Using value = 0:

• Inline math = 127 ko/s.
• If/else = 134 ko/s.

Using value = (integer)llFrand(300)-100, which will obviously be slower than the actual bounds checking itself:

• Inline math = 45 ko/s.
• If/else = 45 ko/s.

Conclusion: perfectly inconclusive and makes sense that I never really saw any tangible improvement, heh.