Boolean logic speed vs if/then statements?

I'm so happy to discover that in LSL TRUE equals one, and FALSE equals zero. This takes me back about ten years to the days of writing programs in Apple II BASIC, and the challenges of writing 1 and 2 line programs that defy normal concepts of program flow to get around language limitations.

I'm wondering if there might be a speed advantage in LSL by using boolean logic rather than nested if-then statements. Anybody know?


Assume:
HorizMove = -1
XPosition = 1
XMin = 1
Xmax = 10
XPosition = XPosition + HorizMove

Code:

XPosition = Xposition + (XPosition < XMin) - (XPosition > XMax)

replaces:

If (XPosition < XMin) { XPosition++ }
If (XPosition > XMax) { XPosition-- }


Here's a more obfuscated route:

Xposition = Xposition * (XPosition => XMin) * (XPosition <= XMax) + XMin * (XPosition < Xmin) + Xmax * (Xposition > XMax)

replaces:

If (XPosition < XMin) {XPosition = XMin}
If (XPosition > XMax) {XPosition = Max}



But is it any faster to do such boolean gymnastics in LSL?

-Scalar

Disclaimer, I know nothing about LSL optimization. In other languages, like C, however, whether you have an if statement or a conditional check in an assignment, like you've shown above, there is still an "if" step being processed. Properly optimization should boil both down to the minimal number of steps.

You could, however, help with the above example by putting an else infront of your second if statement, because the logic of this particular example makes it safe to skip checking the opposite boundary if the first was violated.

I forget the proper term for it, but in C, testing conditions ceases once a confirmed positive or negative is found. ie:

if ( TRUE || test2 || test3 ) { action; }

does't need to evaluate test2 or test3, likewise:

if ( FALSE && test2 && test3 ) { action; }

doesn't need to evaluate test2 or test3

A compiled script should have sufficient smarts to do the least work possible to determine if the whole conditional result will be true or false.

I'm never really sure how clever an optimizer I'm dealing with so I try to help it where I can by making sure the easy and/or likely checks occur first in an if-than-else block so that there's a higher chance of skipping other more resource demanding or less likely tests, ie:

if ( most-likely-and-or-least-complex-condition ) {
} else if ( next-easiest-and-or-probable ) {
} else if ( next-easiest-and-or-probable ) {
} else if ( ... ) {
} else if ( least-likely-or-most-complex-condition ) {
} else {
}

By complex, I mean things like list searches, data retrievial functions like llGetInventory(), string manipulation/searches. The opposite would be checking integer values and such.

And, when it makes sense to do so, I set up different states, so that I don't have to constantly re-check certain conditions (ie, is the sun up? Is there someone sitting on this object? Is the object turned on, or off?).

Anyway, I'm rambling. Hopefully someone more knowledgable will pipe up =)

Is it faster?
In your first example yes.
In your second example no.

Really what it comes down to is operations executed.

If i were (which i wouldn't) to bake out the XPosition ranging it would look like...
Xposition = XMin * temp + Xposition * !((temp = (XPosition < XMin)) | temp) + Xmax * (temp = (Xposition > XMax))

storing is a bit cheeper then recalculating in this instance, as long as we have an extra integer we can mooch. I wouldn't in this instance because it would be more costly. The if structure in this case uses 60 bytes; my code uses 76 bytes (your uses 80 bytes).

You should check out my thread on LSL optimizations: How to optimize code and when not to.

It's good to know there are a few folks left out there with programing habbits as bad as mine.

The phrase you're looking for is lazy evaluation, which is what C and a lot of other languages do. LSL does eager evaluation. It's normally just a case of optimization, but it can actually impact your code more severely if you aren't careful.

For example:

if (TRUE && func ())
{
}

will call func () in LSL but not in C. If func () happens to do something significant, you may be calling it when you don't expect to.

Egads, ick! Yet one more reason to stick to cumbersome but clearer if-then-else blocks instead of trying to clump things cleverly together into a single assignment.

(Thanks for providing the term!)

Sorry, I of course meant:

if (TRUE || func ())

My first version would evaluate func () in both C and LSL.

Yeah, C is evil that way.