Why don't bools have (some) bitwise operators?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Why don't bools have (some) bitwise operators?

Soni "They/Them" L.
Uh bools currently don't have xor so instead you have to write silly
things like

local a = ...
local b = ...
if (a and not b) or (b and not a) then
   ...
end

And it'd look way cleaner with xor

if ... ~ ... then
   ...
end

Thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Gé Weijers


On Tue, Feb 23, 2021 at 9:03 AM Soni "They/Them" L. <[hidden email]> wrote:
Uh bools currently don't have xor so instead you have to write silly
things like

local a = ...
local b = ...
if (a and not b) or (b and not a) then
   ...
end

And it'd look way cleaner with xor

if ... ~ ... then
   ...
end

Thoughts?

If both values are booleans (false or true) then you can do this:
local a = ...
local b = ...
if a ~= b then
...
end

Otherwise do
if not a ~= not b then 
   ...
end


--

Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Gavin Wraith
In reply to this post by Soni "They/Them" L.
In message <[hidden email]>
"Soni \"They/Them\" L." <[hidden email]> wrote:>
Uh bools currently don't have xor so instead you have to write silly

>things like
>
>local a = ...
>local b = ...
>if (a and not b) or (b and not a) then
>   ...
>end
>
>And it'd look way cleaner with xor
>
>if ... ~ ... then
>   ...
>end
>
>Thoughts?

a ~= b ?

--Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/
Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Sudipto Mallick
Look at the following:

X              0  0  1  1
Y              0  1  0  1
X xor Y    0  1  1  0
X ~= Y     0  1  1  0

So in all cases, X xor Y is equivalent to X ~= Y given that X, Y are boolean. Hope that helps.


~smlckz


Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Sean Conner
It was thus said that the Great Sudipto Mallick once stated:
> Look at the following:
>
> X          0  0  1  1
> Y          0  1  0  1
> X xor Y    0  1  1  0
> X ~= Y     0  1  1  0
>
> So in all cases, X xor Y is equivalent to X ~= Y given that X, Y are
> boolean. Hope that helps.

  Also, "and" and "or" in Lua short-circut evaluation.

        if foo() and bar() then ... end

if foo() returns false, bar() is not called (because the rest of the
expression can never be true)

        if foo() or bar() then ... end

if foo() returns true, bar() is never called (because the expression as a
whole is true)

  -spc
Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Sudipto Mallick
On Wed, Feb 24, 2021, 5:19 AM Sean Conner <[hidden email]> wrote:
  Also, "and" and "or" in Lua short-circut evaluation.

        if foo() and bar() then ... end

if foo() returns false, bar() is not called (because the rest of the
expression can never be true)

        if foo() or bar() then ... end

if foo() returns true, bar() is never called (because the expression as a
whole is true)

  -spc

Yes, that's understandable. Short-circuiting for `and` and `or` works because in Boolean algebra, we have:

        1 or A = 1
        0 and A = 0

for any Boolean value of A.

But, in case of `xor`, you need to evaluate both sides to get the result. For example, look at the way OP was doing `xor` from its textbook definition:

        (A and not B) or (not A and B)

Short circuit or not: You need to evaluate both of A and B. If A=1 then the `not B` is evaluated. If A=0 then `(not A and B)` and subsequently `B` is evaluated.


~smlckz




Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Watusimoto


On Tue, Feb 23, 2021, at 19:07, Sudipto Mallick wrote:
On Wed, Feb 24, 2021, 5:19 AM Sean Conner <[hidden email]> wrote:
  Also, "and" and "or" in Lua short-circut evaluation.

        if foo() and bar() then ... end

if foo() returns false, bar() is not called (because the rest of the
expression can never be true)

        if foo() or bar() then ... end

if foo() returns true, bar() is never called (because the expression as a
whole is true)

  -spc

Yes, that's understandable. Short-circuiting for `and` and `or` works because in Boolean algebra, we have:

        1 or A = 1
        0 and A = 0

for any Boolean value of A.

But, in case of `xor`, you need to evaluate both sides to get the result. For example, look at the way OP was doing `xor` from its textbook definition:

        (A and not B) or (not A and B)

Short circuit or not: You need to evaluate both of A and B. If A=1 then the `not B` is evaluated. If A=0 then `(not A and B)` and subsequently `B` is evaluated.


~smlckz


 
A might even be evaluated twice.

C

Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Philippe Verdy-2
In reply to this post by Sudipto Mallick


Le mer. 24 févr. 2021 à 04:08, Sudipto Mallick <[hidden email]> a écrit :
On Wed, Feb 24, 2021, 5:19 AM Sean Conner <[hidden email]> wrote:
  Also, "and" and "or" in Lua short-circut evaluation.

        if foo() and bar() then ... end

if foo() returns false, bar() is not called (because the rest of the
expression can never be true)

        if foo() or bar() then ... end

if foo() returns true, bar() is never called (because the expression as a
whole is true)

  -spc

Yes, that's understandable. Short-circuiting for `and` and `or` works because in Boolean algebra, we have:

        1 or A = 1
        0 and A = 0

for any Boolean value of A.

But, in case of `xor`, you need to evaluate both sides to get the result. For example, look at the way OP was doing `xor` from its textbook definition:

        (A and not B) or (not A and B)

Short circuit or not: You need to evaluate both of A and B. If A=1 then the `not B` is evaluated. If A=0 then `(not A and B)` and subsequently `B` is evaluated.

There's still some short-circuit evaluating both results without needing a temporary variable:
         a() ~= b()

Note however this should be consistant with Lua's booleans (as used with if/ifelse/while/and/or/no), you have to take care of return values other than false or true, notably nil, 0, NaN, all other numbers values (including infinite), strings, or object references (tables, functions, userdata...), so you may need to convert the values to boolean. The simplest way is to use "not" on both sides of the "~=" comparison:

         not a() ~= not b()

which would be what Lua should do if it implements the "xor" operator for booleans (featuring conversion to booleans, like in if/ifelse/while/and/or/not) :

         a() xor b()

such addition of keyword however would requiring defining a priority for the operator, which should be higher than the priority "and", itself having higher priority than "or", so that

   a or b and c xor d

would mean:

   a or (b and (c xor d))

This "xor" boolean operator would implement no short-circuit (both operands being evaluated, the left one before the right one -- the order being important when operands contain function calls or access checks causing errors/exceptions, or "meta" function calls via remapped operators).


Reply | Threaded
Open this post in threaded view
|

Re: Why don't bools have (some) bitwise operators?

Philippe Verdy-2
Also remember that with boolean-only algebra:

a xor b
 ===  (a and not b)   or         (b and not a)
 ===  not(a or b)     and  not (not a or not b)

So the xor can be both canonicalized as an or-list of and-list of single boolean tests, or an and-list of or-list of single-boolean tests ("tests" being evaluating if they are false or true, with an "identity" or "complementary not" function); that's why "xor" should have higher priority than "or"/"and", but not placed in the middle of them (because "or"/"and" implement shortcuts on the evaluation of their operands, which "xor" would not as it would behave like other binary operators like "+", "*", "==", "~=", ">", and so on).



Le mer. 24 févr. 2021 à 16:01, Philippe Verdy <[hidden email]> a écrit :


Le mer. 24 févr. 2021 à 04:08, Sudipto Mallick <[hidden email]> a écrit :
On Wed, Feb 24, 2021, 5:19 AM Sean Conner <[hidden email]> wrote:
  Also, "and" and "or" in Lua short-circut evaluation.

        if foo() and bar() then ... end

if foo() returns false, bar() is not called (because the rest of the
expression can never be true)

        if foo() or bar() then ... end

if foo() returns true, bar() is never called (because the expression as a
whole is true)

  -spc

Yes, that's understandable. Short-circuiting for `and` and `or` works because in Boolean algebra, we have:

        1 or A = 1
        0 and A = 0

for any Boolean value of A.

But, in case of `xor`, you need to evaluate both sides to get the result. For example, look at the way OP was doing `xor` from its textbook definition:

        (A and not B) or (not A and B)

Short circuit or not: You need to evaluate both of A and B. If A=1 then the `not B` is evaluated. If A=0 then `(not A and B)` and subsequently `B` is evaluated.

There's still some short-circuit evaluating both results without needing a temporary variable:
         a() ~= b()

Note however this should be consistant with Lua's booleans (as used with if/ifelse/while/and/or/no), you have to take care of return values other than false or true, notably nil, 0, NaN, all other numbers values (including infinite), strings, or object references (tables, functions, userdata...), so you may need to convert the values to boolean. The simplest way is to use "not" on both sides of the "~=" comparison:

         not a() ~= not b()

which would be what Lua should do if it implements the "xor" operator for booleans (featuring conversion to booleans, like in if/ifelse/while/and/or/not) :

         a() xor b()

such addition of keyword however would requiring defining a priority for the operator, which should be higher than the priority "and", itself having higher priority than "or", so that

   a or b and c xor d

would mean:

   a or (b and (c xor d))

This "xor" boolean operator would implement no short-circuit (both operands being evaluated, the left one before the right one -- the order being important when operands contain function calls or access checks causing errors/exceptions, or "meta" function calls via remapped operators).