& and &&

I recently had some scripts fail that had been working properly for months, turned out some if() statements with multiple conditions required && rather than & between them:

if((llListFindList(gList,[test]) == -1) && (test2 != "*")
{

}


Now I technically understand the difference between logical & boolean comparisons but am a bit hazy on the correct implementation given it would seem either might work, and am completely baffled why one implementation (using a single & would work and then recently fail.

Any Ideas?

You know binary numbers?
Here is an example(binary numbers with a 'b' in the end)
integer x=1001b;
integer y=1010b;
integer z=0100b;
integer w=0000b;

( x && y && z ) == 1. None of the numbers are zero, so it is TRUE

( x & y & z ) == 0000b, so it is FALSE.

using x, y, and w, both would be FALSE and the program would work the same.

its simple enough:

& is a bitwise AND operator, like + is addition and - is subtraction
&& is a comparative AND, like in a spoken sentence, "The music was good AND the newbies at that club were annoying".

so, if you use that in an if() clause, the bitwise and _might_ work but also might fail...

lets do an example...

integer a=TRUE;
integer b=TRUE;

if(a&b) <--- TRUE (bitwise and) TRUE is TRUE, so the if clause gets executed
if((a==TRUE)&&b==TRUE)) <--- same thing, actually
if((a==TRUE)&b==FALSE)) <--- result of left () is true, right is false, bitwise and of that is false, no execution
if((a==TRUE)&&b==FALSE)) <--- same thing again


rule of thumb:
in if() clauses, use && to concatenate several checks on variables;
use bitwise operators to mask with flags.
example: if(x&ALL_SIDES) // do something if the "ALL_SIDES" bit is set in the variable x

Thanks, your explanations were very clear, but it doesn't explain the recent change in behaviour of my script example.

It's been working for months with

if((condition 1) & (condition2))

and suddenly stopped working, requiring me to rewrite it (correctly) as:

if((condition 1) && (condition2))

As you can see, I did understand the difference, and thus corrected my original mistake, however if we assume that TRUE = 1 & FALSE = 0, then if both my conditions are TRUE, then the result of if(1 & 1) should still yield the correct response surely ?

I have a suspicion LL recently changed something in the way TRUE & FALSE are represented perhaps...

This is where you are wrong, value 1 is TRUE but TRUE is any value not equal to 0.
So (4 && 1) is TRUE but (4 & 1) is FALSE

I doubt that, take a closer look at your arguments and investigate what changes has happened.

OK, you took my example too literally

In all cases I'm testing conditions that are TRUE or FALSE,

if((a == b) & (llListFindList(list,[test]) != -1))

etc...

I do understand what you're saying, but I believe my specific example should yield the result I expected, even if it's semantically the wrong way of going about it.

The fact that it stopped working when nothing had changed is what really confused me. It had worked for weeks, rezzing room sets, and then suddenly it was failing to build an inventory list of inventory that hadn't changed either.

Nobody promised us that that a true expression has the value 1
I would never rely on it. All I know is that it is not 0.

Oh yes they did:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=constants

to further illustrate the point...

in some scenarios it might work such as (a == b) type comparisons, where a single default value is returned for the expression. but if you toss in something that might NOT result in a strict comparison, like say (~llListFindList( a, b )) then a bitwise operation will definitely have instances of failure, because the 'truth is test as 0 = FALSE, anything else = TRUE. it could be that 'anything else' is frequently 1 and so 'usually works... but is logically wrong as a test (for your purpose)

now I'd guess that the statement
if((a == b) & (llListFindList(list,[test]) != -1));
would work as you hoped, however I've never actually tested != return values, so don't know explicitly if it only returns the same values as ==. it may not.

reasons could include accidentally different implementations (kinda stupid reason), purposefully different implementations (to allow extra information, like what the difference is), or even a change in implementation (for one of those reasons or something more obscure).

but it's logically wrong to test the individual bitmask of each statement, when what you want to test is the overall truth of the statements.

failures would include false negatives for any numbers that the set bits didn't have matches between both results. ex: (1 & 2) = false, (1 && 2) = true


actually no, they didn't. just because a constant has a single default value (like TRUE) does not mean that evaluation logic strictly uses the constant definition. secondly you quoted it from a non LL source which means someone else is saying it (ie not an LL promise), and finally, LL has been known to change, add, and remove behaviors in lsl... including changing the default value of a constant (like PRIM_TYPE).

[never mind that TRUE is a variable name, not an evaluation criteria, and therefore not a reciprocal property, TRUE evaluates as true, but all things that evaluate as true do not necessarily = TRUE, semantics count here]

boring footnote:
one of the reasons some languages use -1 as the default value is because it has all bits set, so can avoid the above problem in logic (so & will always return a true comparison with any non zero number comparing a default... does nothing for comparing non defaults though.)

Yep, yep, yep... I haven't disagreed with anything anyone's said in principle, citing only very explicit examples where theoretically I should get the response I was expecting despite my error - which I unconditionally accept!

What really bugs me is that the behaviour changed and I don't know why.

On most compilers, all the conditions in an 'if' statement are reduced to numbers then sorta evaluated as a simple true/false operation.

So, for example, if you had 'if (llSubStringIndex ("cat", "z" & x == 42)', the whole 'if' would always be true if x actually had a value of 42. The llSubStringIndex returns -1 (all bits = 1) if it doesn't find a string match.

Similar, you can get weird and unexpected results if you had, say, ("cat", "a" because that would return a 1, which looks a lot like TRUE. Or ("cat", "c" would return a 0 and cause any bitwise-AND to fail...


Though it's incorrect with a single &, I don't see why this wouldn't work anyway.

I haven't mucked around with exact comparison operator result values, nor have I seen anyone else experiment thoroughly. Perhaps someone like Strife who has mucked around with the LSL compiler could tell us. Then again, I'd applaud LL for not making the Mono transition depend on this kind of behavior that scripters should never base their logic on, if that's what they did.

Some languages return something like one of the operator's parameters (e.g. one of the values in a chain of &&, ||). It is more common for the boolean operators than for comparison operators, but for example there's no reason that the != operator acting on two integers or floating point numbers couldn't return the difference between the left and right expression values.

I have been known to say stupid things, but there's been, and still is, a rolling restart going on.
The reason of which being:

Maybe that's why.

Not sure if this applies to LSL, but c# works like this.

did anyone test short ciurcutting in mono? I know that LSL doesn't handle that, but maybe that was changed with mono.

I tested in on the Beta Grid in the early days of Mono and it behaved just like the pre-Mono LSL behavior (i.e. no short-circuiting).

What a shame

Yea, I just tested it too. Seems SL don't use short circuit operators.

You can ignore what I posted earlier I suppose.