If loop - end

Kicking myself in the butt here - this should be second nature. I want to do something like this:

Get a vector
integer stuffing = y

If stuffing == 3
statement
end
If stuffing == 4
statement
end
else
stuffing = x

If stuffing == 23
statement
end
If stuffing == 41
statement
end
etc.

if (stuffing == 3) llOwnerSay("Stuffing is 3";

-- or --

if (stuffing == 3)
{
llOwnerSay("Stuffing is 3";
// more statements
}

If stuffing is not changed by the statements


if (stuffing == 3) llOwnerSay("Stuffing is 3";
else if (stuffing == 4) llOwnerSay("Stuffing is 4";
else if (stuffing == 23) llOwnerSay("Stuffing is 23";
else if (stuffing == 41) llOwnerSay("Stuffing is 41";

-- or --

if (stuffing == 3)
{
llOwnerSay("Stuffing is 3";
// more statements
}
else if (stuffing == 4)
{
llOwnerSay("Stuffing is 4";
// more statements
}
else if (stuffing == 23)
{
llOwnerSay("Stuffing is 23";
// more statements
}
else if (stuffing == 41)
{
llOwnerSay("Stuffing is 41";
// more statements
}

Leave out the else when statements influence the value of Stuffing

Remember nested ifs in LSL are limited. (You get an error if you add too many).

Best is to use something like this:

if (stuffing == 0) {
llOwnerSay("0";
return;
}
if (stuffing == 1) {
llOwnersay("1";
return;
}

That way you can go to 41...
Of course you can't put any more logic at the end of the if structure now. So make sure you don't need to, or use a function.

don't think that is it

Thats what I was looking for 'return;' - bloody obvious - thanks

binary trees, you'd only need 4 levels of if's to cover 41 choices (with a few tacked on elseif's at the bottom) nad only 4-5possible testests beforefinding any answer

//-- binary if tree using different methods on a 0-7 range, with out of range checking
//-- only 2 levels ofnesting, and 3-4 tests max for any value (only 3 if you can control the input)
if (4 > answer){ //-- low answers, like 0-3
  if (2 > answer){
    if (0 > answer){
      //-- #<0
    }else if (0 == answer){
      //-- #0
    }else{
      //-- #1
    }
  }else{ //-- 4> answer >= 2
    if (2 == answer){
      //-- #2
    }else{
      //-- #3
    }
}else{ // answer >= 4
  if (6 > answer){
    if (answer % 2){ //-- alternate way to test against odd vs even
      //-- #5
    }else{
      //--#4
    }
  }else{
    if (6 == answer){
      //-- #6
    }else if(7 == answer){
      //-- #7
    }else{
      //-- #>7
    }
  }
}

Re binary trees...

That binary decision tree used 9 IF tests to distinguish 10 cases, saving nothing. To overcome the limit on ELSE-IF chains isn't it simpler to nest chains at the end of a chain?

If ... Else if ... Else If ... ...
Else { if ... Else if ... ...}

And so on. (Sorry, but this seems relevant and not like hijacking the thread.)

The purpose of binary trees is that they are much faster. 41 if's/else if's are only fast if the selection is in the upper range, but it takes considerable time and more work for the simulator to get to the 41st. With a 4 level binary tree, it takes the same resources to reach the 41st as it does the linear test to reach the 4th.

Here is a thread where we discussed and tested if/else if the the nth degree:

/54/02/144383/1.html

Not binary trees. Hash codes. Exercise left for the student.

No, no, wait...A* search for the right result. That's the ticket...

No, no, better yet. LSL needs a new function

llReadProgrammersMind() All scripts can be reduced to one function call.

Yaya!!!!

Hey Lee! Am I detecting a mischievous, 4 glorious days off work mood going on over your way??? If I am right then I guess that means I used llReadOtherProgrammersMind().

Happy Thanksgiving to the ones in the US and TGIF to the rest of you!

saving execution time, and deeply nested if's was the point...not coding amount.

although straight numerical data isn't the the best use, since a single indexed list could contain all the answers, and bitwise comparisons could be used w/ some modifications too...but it is a structure that people should be aware of for fast searching of large ORDERED lists, but also good for assymetrical data/actions (which seemed possible from OP)

I see the original binary tree post was about nesting levels for sure. Execution time is a win if the datum to be tested is evenly distributed. Trees are a good idea and worth remembering as an implementation pattern.