Operator logical / bitwise "AND"

[testgenord1]

Hi!
I have a script containing 2 conditions.
The script is only supposed to start when both conditions are fulfilled:

integer detectedlinknumber = llDetectedLinkNumber(0);
list listx = ["one", "two", "three"]; //random example of a list
integer listlength = llGetListLength(listx);

//condition 1:
if(detectedlinknumber != 1) //The link must not be the root prim (linknumber 1)

AND

//condition 2:
if(detectedlinknumber <= listlength) //The linknumber must be smaller or equal to the number of entries on the list.

I tried the following methods, which both failed:   

if(detectedlinknumber != 1 & detectedlinknumber <= listlength)   

                                                             
if(detectedlinknumber != 1 && detectedlinknumber <= listlength)

Do you maybe know how to do this right?
Thank you very much in advance!

[Quistess Alpha]

6 minutes ago, testgenord1 said:

if((detectedlinknumber != 1) && (detectedlinknumber <= listlength))

 

FIFY, you want '&&' because you're doing a logical operation, not bitwise (although in this case '&' would actually work the same) and it's always a good idea to make your parenthization unambiguous, despite what the order of operations might say

[Lucia Nightfire]

2 hours ago, Quistess Alpha said:

FIFY, you want '&&' because you're doing a logical operation, not bitwise (although in this case '&' would actually work the same) and it's always a good idea to make your parenthization unambiguous, despite what the order of operations might say

With as much LSL code as I've seen from others over the years, there seems to be a disdain for parenthesis as much as there is for if statement brackets. 😆

[Quistess Alpha]

2 minutes ago, Lucia Nightfire said:

With as much LSL code as I've seen from others over the years, there seems to be a disdain for parenthesis as much as there is for if statement brackets. 😆

if you don't like parentheses, you should switch everything to prefix or postfix notation. Completely unambiguous:

detectedLinkNumber listLength <=  detectedLinkNumber 1 != &&

or for an actual postscript example, see:

 

[Profaitchikenz Haiku]

25 minutes ago, Lucia Nightfire said:

With as much LSL code as I've seen from others over the years, there seems to be a disdain for parenthesis as much as there is for if statement brackets.

Speaking personally, the more characters one types, the greater the potential for errors.

But in fact I am a great believer in parentheses when working with logical expressions, just not so much in the use of braces when there's just a single statement.

[testgenord1]

2 hours ago, Quistess Alpha said:

FIFY, you want '&&' because you're doing a logical operation, not bitwise (although in this case '&' would actually work the same) and it's always a good idea to make your parenthization unambiguous, despite what the order of operations might say

Thank you so much for your quick reply!
I don't know why, but this still did not solve the problem (I tried both the logical and bitwise version).

I ended up using the following version, which now works:

if(detectedlinknumber != 1) 
{
 if(detectedlinknumber <= listlength)
 { ...

In terms of programming logic, this should be exactly the same thing.
I really don't understand why the versions using "&" do not work with me.
Sometimes certain things just don't work on my region (Opensim), for whatever reason.

So, just out of curiosity, in case you have more ideas, feel free to comment further.
 

Besides: (If you feel like explaining it) what exactly is the difference between "logical" and "bitwise"?

[Profaitchikenz Haiku]

This is best described by the LSL Portal, but to grossly simplify it

 

&& looks to see if each side is not all 0s ( if 1 && 2 will be true, if 2 && 0 will be false)

& looks to see if one specific bit in both sides is not 0 ( if 6 & 2 will return true because each has the same bit set in the position for 2, if 4 & 3 will return false since 4 does not have the same lowest 2 bits turn on that 3 does)

 

[Quistess Alpha]

2 minutes ago, Profaitchikenz Haiku said:

& looks to see if one specific bit in both sides is not 0 ( if 6 & 2 will return true because each has the same bit set in the position for 2, if 4 & 3 will return false since 4 does not have the same lowest 2 bits turn on that 3 does)

There's no such thing as 'true' and 'false' in LSL, except for the constants TRUE == 1; and FALSE == 0;

LSL's if statement has some quite convenient type interpretations though.

It is more correct to say:

&& is an operator that takes two integer arguments. it returns 0 if either argument is 0, otherwise it returns 1; 6&&2 = 1, 4&&3 = 1, 4&&0 = 0.

& is an operator that also takes two integer arguments. it looks at both its arguments in binary and compares each spot bit by bit. if both bits in the same position are 1, the output in that position is 1, otherwise the output in that position is 0. 6&2 -> 110&010 = 010 -> 2 ; 4&3 -> 100&011 = 000 -> 0.

TL;DR 6&2 is 2 which is not 'TRUE'.

[testgenord1]

Wow, thank you very much for your explanation, guys!
I'll need some time to read through this in detail.
I'll do that during the week.
Thank you so much, again!👍🙂

[Mollymews]

both Bitwise and Logical methods examples in the OP are correct in this case

so there is something else happening after the evaluation which is giving an erroneous result

it could be the incorrect mapping of detectedlinknumber to the correct index of listx.  In a linkset, the index (detectedlinknumber) is 1-based.  A list index is 0-based.  We need to deduct 1 from detectedlinknumber to get the corresponding list index

if is not this then is something else following the evaluation

both methods are correct in this case, as the two conditions both result in the 1-bit (boolean) values of either TRUE or FALSE

showing by example:

default
{
  state_entry()
  {
      integer detectedlinknumber = 2;  // llDetectedLinkNumber(0);
      
      list listx = ["One", "Two", "Three"];
      integer listlength = llGetListLength(listx);  // listlength == 3
      
      if (detectedlinknumber != 1 & detectedlinknumber <= listlength)
          llOwnerSay("BITWISE: when detectedlinknumber is not 1 AND detectedlinknumber is less than or equal to 3 then this is TRUE");
      else
          llOwnerSay("BITWISE: when detectedlinknumber is 1 OR detectedlinknumber is greater than 3 then this is FALSE");
      
      if (detectedlinknumber != 1 && detectedlinknumber <= listlength)
          llOwnerSay("LOGICAL: when detectedlinknumber is not 1 AND detectedlinknumber is less than or equal to 3 then this is TRUE");
      else
          llOwnerSay("LOGICAL: when detectedlinknumber is 1 OR detectedlinknumber is greater than 3 then this is FALSE");
    }       
}

 

this said, using parentheses is always a good thing for readability, even when by order of precedence the parentheses are not necessary

when the conditions evaluate to boolean TRUE or FALSE then use the bitwise operator &. As is a tiny bit more efficient than the logical operator &&

info on order of precedence is here: http://wiki.secondlife.com/wiki/LSL_Operators

 

ps add:

given the condition: detectedlinknumber != 1 & detectedlinknumber <= listlength

then the evaluation by order of precedence is:

resultA = detectedlinknumber <= listlength

resultB = detectedlinknumber != 1

finalresult = resultB & resultA

 

Edited November 1, 2021 by Mollymews

[Profaitchikenz Haiku]

Incorrecto, ergo sum

[testgenord1]

On 11/1/2021 at 10:42 PM, Mollymews said:

both Bitwise and Logical methods examples in the OP are correct in this case

so there is something else happening after the evaluation which is giving an erroneous result

it could be the incorrect mapping of detectedlinknumber to the correct index of listx.  In a linkset, the index (detectedlinknumber) is 1-based.  A list index is 0-based.  We need to deduct 1 from detectedlinknumber to get the corresponding list index

if is not this then is something else following the evaluation

 

ps add:

given the condition: detectedlinknumber != 1 & detectedlinknumber <= listlength

then the evaluation by order of precedence is:

resultA = detectedlinknumber <= listlength

resultB = detectedlinknumber != 1

finalresult = resultB & resultA

 

Thank you very much for the explanations of the three of you!🙂
I think I have understood the difference.

@Mollymews: Your idea was correct.
I forgot to clearly define "detectedlinknumber" as a global variable,
consequently setting it to ZERO in the touch_start event, automatically rendering the condition as false.🤦‍♂️
The bitwise and logical "AND" both work in the script now.
 

I tried to apply your example to my script.
Did I understand it correctly?
(This is more theoretical now, so only reply if you feel like it.)

resultA = detectedlinknumber <= listlength //if TRUE then the result would be "1", binary: 0001

resultB = detectedlinknumber != 1 //if TRUE then the result would be "1", binary: 0001

finalresult = resultB & resultA //comparing 0001 and 0001 = 0001, decimal: 1, Boolean: TRUE

Is that how it works?

 

Edited November 6, 2021 by testgenord1

[Quistess Alpha]

4 hours ago, testgenord1 said:

resultA = detectedlinknumber <= listlength //if TRUE then the result would be "1", binary: 0001

resultB = detectedlinknumber != 1 //if TRUE then the result would be "1", binary: 0001

finalresult = resultB & resultA //comparing 0001 and 0001 = 0001, decimal: 1, Boolean: TRUE

Is that how it works?

Yes, and as @Mollymews pointed out earlier, both '&' and '&&' would give you the same result on that last line.

It's good to keep in the back of your mind though, that '&' might give unexpected results if one of the arguments (results in your case) were not always boolean (either 1 or 0 and not, for example, 2).

[Mollymews]

9 hours ago, testgenord1 said:

Did I understand it correctly?

yes, you are onto it