Clamping (or range limiting) Vector Elements?

==== EDIT UPDATE! ====
final, optimized function(s) can now be found at

==== EDIT UPDATE! ====

ok this has annoyed me for awhile... I can't find any simple (or Complex) mathematical way to apply limits to the values in a vector without taking it completely apart and addressing each element individually. I'd be less annoyed if I could loop through it, but that's not possible either.


I'm offering a 2,000L$ 'Vanity' Prize to anyone that has a solution that can pull this trick off with a single incoming function call either without taking the vector apart, or can run a faster smaller code (somehow looping it?) than the following example

//-- storage for max as called in the main function
//-- saved 1 byte in LSO
//-- saved 4 bytes in Mono
float gFltMax;
//-- very bad form, messes with portability

//-- don't worry about sanitizing input, assume it happens in the main code
vector fVecRange( vector vVecRaw, float vFltMax ){
    gFltMax = vFltMax;
    return < fFltRange( vVecRaw.x ),
            fFltRange( vVecRaw.y ),
            fFltRange( vVecRaw.z )>;
}

//-- to make this simple, assume a lower range 0, upper range >= 0, input of any valid float
float fFltRange( float vFltRaw ){
    if (0 > vFltRaw){
        return 0;
    }else if (gFltMax < vFltRaw){
        return gFltMax;
    }
    return vFltRaw;
}

//-- no changing this part except the single function call, keep the values
default{
    state_entry(){
        llOwnerSay( (string)llGetFreeMemory() );
        //-- this part MUST be a single function call, with a vector and the top range
        llOwnerSay( (string)fVecRange( < -.5, .5, 2.>, 1.5 ) );
        //-- yes I know I can save by pairing it with global sets, but that
        //-- makes it less clean/portable so we won't be having any of that!
    }
}
//-- Viewer: (doesn't need to match it's just reference)
//-- 1.21.6 (99587)
//-- Server: (should probably match, 1.26 & 1.27 are buggy atm)
//-- 1.25.6.113484

//-- MONO results:
//-- Object: 61152
//-- Object: < 0.00000, 0.50000, 1.50000>

//-- LSO results:
//-- Object: 15888
//-- Object: < 0.00000, 0.50000, 1.50000>

hmmm seems there's some funkiness in how MONO reports get free memory, the LSO test is probably better.

Oh, lots and lots of funkiness, as in next to useless. It can vary with the same compile and inputs running in the same sim, the free memory gets reset by an indeterminate amount on sim crossings, and I suspect that even recompiling can have an effect. The new scheduler on aditi reduces the variability but doesn't eliminate it.

I don't have an answer, but I can sort of see one.

Your bounds are like a box with a corner at <0,0,0>, and your vector starts at <0,0,0> and goes to <x,y,z>, right? You want to keep the part of your vector that is inside the box.

Seems like there must be some sort of clever clip-off-the-extra bit function.

Well, here's a quick hack to ensure that all three elements of the vector are >= 0:

<vec.x > 0) * vec.x, (vec.y > 0) * vec.y, (vec.z > 0) * vec.z>

I can't think of a better way to bound the vector components to a non-zero limit though.

LOL, 30 bytes

vector fVecRange( vector vVecRaw, float vFltMax ){
    return <(vVecRaw.x > 0.0) * ((vVecRaw.x <= vFltMax) * vVecRaw.x) + ((vVecRaw.x > vFltMax) * vFltMax),
            (vVecRaw.y > 0.0) * ((vVecRaw.y <= vFltMax) * vVecRaw.y) + ((vVecRaw.y > vFltMax) * vFltMax),
            (vVecRaw.z > 0.0) * ((vVecRaw.z <= vFltMax) * vVecRaw.z) + ((vVecRaw.z > vFltMax) * vFltMax)
           >;
}

default{
    state_entry(){
        llOwnerSay( (string)llGetFreeMemory() );
        //-- this part MUST be a single function call, with a vector and the top range
        llOwnerSay( (string)fVecRange( <-.5, .5, 2.>, 1.5 ) );
        //-- yes I know I can save by pairing it with global sets, but that
        //-- makes it less clean/portable so we won't be having any of that!
    }
}

I did this on 1.26.2 because 1.25 is hard to find now

//-- MONO results:
//-- Object: 61668 first run 1.26, 61692 after reset
//-- Object: <0.00000, 0.50000, 1.50000>

//-- LSO results:
//-- Object: 15918
//-- Object: <0.00000, 0.50000, 1.50000>

ETA:
nice cerise, I'll try to test that today and pick it apart =) with luck it'll run faster too (not an absolute requirement).

PS. you guys let the 50 poster beat you? =P j/k
(post_count != experience/creativity or the fact that it could have been built off the previous post ideals)


it was odd, accross multiple recompiles, I added code to a mono function (an if & a variable = 3) and the immediately reported free memory after did NOT change. (I used the same essential reporting as above, get free memory, then the function call) so yeah, buggy as hell. I'll try to jira that today with a demo script.

it may just be a matter of the JIT compilation nature of MONO on the servers but it doesn't smell right even for a function as poorly named and reported as get free memory.

I like how you are thinking Lee and Argent... I'll try to play with something along those lines today if my isp cooperates

Brute force bunny!

wait... they're still rolling out 1.26 that they haven't fixed the permission bug in it yet? o.0

It looked like 1.26.2 really fixed the permission problem, did it change again?

grrrrrr *kicks my self*
I popped over to ask Prospero a couple of questions this morning. I mentioned that the fix in Aditi did indeed work but forgot to ask what the MG rollout timeline was going to be.

The good news I put in the other thread about TP. The bad news was that he didn't even know what I was talking about when I asked about the UI change to show script memory I pinged Vektor, but he is the lead server QA now and he didn't know either. If anyone hears anything let me know.

EDIT: And way to go Bunny!!!!!!!!!

very slight optimization on Cerise' code (15Bytes)

vector fVecRange( vector vVecRaw, float vFltMax ){
    return <(vFltMax > vVecRaw.x && vVecRaw.x > .0) * vVecRaw.x,
            (vFltMax > vVecRaw.y && vVecRaw.y > .0) * vVecRaw.y,
            (vFltMax > vVecRaw.z && vVecRaw.z > .0) * vVecRaw.z>
           + <(vFltMax <= vVecRaw.x),
              (vFltMax <= vVecRaw.y),
              (vFltMax <= vVecRaw.z)> * vFltMax; 
}

//-- no changing this part except the single function call, keep the values
default{
    state_entry(){
        llOwnerSay( (string)llGetFreeMemory() );
        //-- this part MUST be a single function call, with a vector and the top range
        llOwnerSay( (string)fVecRange( <-0.5, 0.5, 2.0>, 1.5 ) );
        //-- yes I know I can save by pairing it with global sets, but that
        //-- makes it less clean/portable so we won't be having any of that!
    }
}

//-- LSO:
//-- Object: 15933
//-- Object: <-0.50000, 0.50000, 1.50000>

//-- MONO:
//-- Object: 61668
//-- Object: <-0.50000, 0.50000, 1.50000>

//-- ok seriously wtf? mono stats are useless to test script size in memory

and the speed comparison....

vector fVecRange1( vector vVecRaw, float vFltMax ){
    gFltMax = vFltMax;
    return <fSubVecRange( vVecRaw.x ),
            fSubVecRange( vVecRaw.y ),
            fSubVecRange( vVecRaw.z )>;
}
float gFltMax;
float fSubVecRange( float vFltRaw ){
    if (0 > vFltRaw){
        return 0;
    }else if (gFltMax < vFltRaw){
        return gFltMax;
    }
    return vFltRaw;
}

vector fVecRange2( vector vVecRaw, float vFltMax ){
    return <(vFltMax > vVecRaw.x && vVecRaw.x > 0) * vVecRaw.x + (vFltMax <= vVecRaw.x) * vFltMax,
            (vFltMax > vVecRaw.y && vVecRaw.y > 0) * vVecRaw.y + (vFltMax <= vVecRaw.y) * vFltMax,
            (vFltMax > vVecRaw.z && vVecRaw.z > 0) * vVecRaw.z + (vFltMax <= vVecRaw.z) * vFltMax>;
}

vector fVecRange3( vector vVecRaw, float vFltMax ){
    return <(vFltMax > vVecRaw.x && vVecRaw.x > .0) * vVecRaw.x,
            (vFltMax > vVecRaw.y && vVecRaw.y > .0) * vVecRaw.y,
            (vFltMax > vVecRaw.z && vVecRaw.z > .0) * vVecRaw.z>
           + <(vFltMax <= vVecRaw.x),
              (vFltMax <= vVecRaw.y),
              (vFltMax <= vVecRaw.z)> * vFltMax;
}



//--------------------
integer time() { // count milliseconds since the day began
    string stamp = llGetTimestamp(); // "YYYY-MM-DDThh:mm:ss.ff..fZ"
    return (integer) llGetSubString(stamp, 11, 12) * 3600000 + // hh
           (integer) llGetSubString(stamp, 14, 15) * 60000 +  // mm
           llRound((float)llGetSubString(stamp, 17, -2) * 1000000.0)/1000; // ss.ff..f
}
 
default {
  state_entry() {
    llOwnerSay((string) llGetFreeMemory());
 
    //test variables
    float counter;
 
    //framework variables
    float i = 0;
    float j = 0;
    float max = 10000; // 2ms of work takes 20 seconds to repeat 10,000 times, plus overhead
 
    float t0 = time();
    do {

      //-- swapped these between tests --//
//      fVecRange1( <-.5, .5, 2.>, 1.5 );
//      fVecRange2( <-.5, .5, 2.>, 1.5 );
      fVecRange3( <-.5, .5, 2.>, 1.5 );

      counter += 1;
 
    }while (++i < max);
    float t1 = time();
    do ; while (++j < max);
    float t2 = time();//remove the time required by the framework
    float elapsed = ((t1 - t0) - (t2 - t1))/max;
    llOwnerSay("The function in the loop took a total of " + (string)elapsed + " milliseconds.");
  }
}

//-- LSO tests:
//-- Object: The function in the loop took a total of 4.275100 milliseconds. (my original version)
//-- Object: The function in the loop took a total of 3.455100 milliseconds. (Cerise' orignal version)
//-- Object: The function in the loop took a total of 3.417500 milliseconds. (My tweak of Cerise' version)

//-- MONO tests:
//-- not included because they frequently yeilded negative results.

//-- Server 1.26

no other attempts? mind if I give em a day to try Cerise? (why does it always seem like it's the ones with the rabbit ears that are tuned in?)

PS today's stupid people trick? (0 < X < Y) [which acts like (0 < (X < Y)) but I'll try anything], reducing the upper range by subtraction after clearing the lower range didn't yeild anything smaller than Cerise' original either

(ps, ok I missed the update on the status of that nextowner perm taking over the current owner perm bug, good to see that piece was nixed)

Oh yes, leave it open, please! I want something better too, it's exactly what I was chewing on with my llTarget obsession. That's a kitty in the tiny picture but there was bunnehness last week!

oops =X I cued of of argent, and it's a lil dark on my screen... sorry =) (although it was a compliment meant to also catch a certain other bunny-eared person, whom I hope is doing well)

I'd hate to think this is the best we can do (no offense). it's just that both our solutions lack elegance (HAH in LSL, what am I saying ?!?)

I'd say the OP gets the prize. Readability and maintainability over performance any day of the week, even in memory-/performance-constrained LSL!

(Very bad form to depend on the true value of a boolean expression always being one! Yes, a triple-operand conditional expression would be very nice to have.)

Ugh oh this is bad. Ferrets are supposed to be smarter the cats.

but what's hotter than a habenero ?

(funny that my kitty pick is still my inworld profile)

I had a Cabbit sighting... I am hopeful >=)

oh I dunno about that. conditional behavior tends to be locked in most languages, and between the fact that it's defined for the constant AND would break insane amounts of scripts if they changed either the behavior or the constant I'd call it a pretty safe bet. at least safer than many other bets in LSL (warpPos anyone?)... then again we've got that odd space stripping going on with mono keys so who knows for sure :hrug::

(I did strip Cherise' version into a double function like mine when testing, and it is smaller than the ifs, but still bigger than the kitty original)

Some people say the Bhut Jolokia but they would be wrong and I didn't know it till recently. It is actually the wild desert tepin, a little, tiny pepper. I find that funny because both my Dad and a lot of people grow them in South Texas. We always used to have a bottle of them pickled in vinegar on the table and used it a lot. Just a couple of drops thou, you do not "eat" tepins *shudders at the thought*. I am a chili-head and have always wanted to try eating that Jolokia pepper but there is no way in hell I would do that with a tepin.


Cabbits seem to be shy and fleeting now. I sent Strife a PM but he had already logged off. Miss his insight and presence here in the forums.

I'm working on an installer problem with Windows 2008 on Itanium. My brain is overflowing with broken XML.

Nuh, putting my language lawyer hat on... the definition of booleans in LSL specify that the true value is 1. It would break much much more than this if (a < b) was ever equal to anything but 1 or 0.

so that's what those are... had a friend that grew wome in their garden... they gotten them from texas.... drop one of those tiny lil suckers in a soup kitchen size pot of chili and that was it.... she didn't know what they were called, just called em peter peppers


as I understand it, Strife's at a point similar to where I was IRL a while back. seems to be doing better with it than I was though.

OOH I'm sad to see less cabbit, OTOH I'm almost glad I didn't catch strife's interest with this, since it usually ends with me doing a facepalm and going "why didn't I think of that?"

@Heewee:
could be worse we could be stuck with VB's 16 bit -1 = TRUE and all the inherent problems created by logical operations between it and 32/64bit data.

we'll close this out sunday eve (unless someone objects) to give the weekend crowd a chance to do a once over on it.

PS don't bother testing this in MONO, the inaccuracies can't be accounted for yet.

last chance....

ok closing the book on this one.... Cherise' your check is in the mail (seriously, I'll log in tonight to pass you the prize.) I'm gonna library the function with comments.

optimized function can now be found at