What is the difference between bitwise and logical operators?
646 views
Skip to first unread message
Ford Ox
May 30, 2016, 2:30:22 AM5/30/16
to julia-users
For example
Is it just artifact from c where bool types don't exist?
true & false == true && falseIs it just artifact from c where bool types don't exist?
Kaj Wiik
May 30, 2016, 3:58:02 AM5/30/16
to julia-users
Here's a clue:
julia> 0b10010011 & 0b10010011
0x93
julia> 0b10010011 && 0b10010011
ERROR: TypeError: non-boolean (UInt8) used in boolean context
Kaj
Ford Ox
May 30, 2016, 6:54:15 AM5/30/16
to julia-users
Ye I know what bitwise operator does.
I will ask in different way, maybe it will be clearer to you.
Why people use logical operators ( f.e. in conditions ) instead of bitwise operators? Is && <: & ?
I will ask in different way, maybe it will be clearer to you.
Why people use logical operators ( f.e. in conditions ) instead of bitwise operators? Is && <: & ?
Scott Jones
May 30, 2016, 7:00:52 AM5/30/16
to julia-users
The && and || operators are conditional, as in other languages.
The second operand is not always evaluated.
The second operand is not always evaluated.
Tamas Papp
May 30, 2016, 7:19:05 AM5/30/16
to julia...@googlegroups.com
See
http://docs.julialang.org/en/release-0.4/manual/control-flow/#man-short-circuit-evaluation
A lot of effort went into writing and improving the language manual, so
that you can find very detailed answers to questions like this one. It
is fine to ask on the list if you can't find it, but giving the whole
manual a read is very useful for new users of Julia.
http://docs.julialang.org/en/release-0.4/manual/control-flow/#man-short-circuit-evaluation
A lot of effort went into writing and improving the language manual, so
that you can find very detailed answers to questions like this one. It
is fine to ask on the list if you can't find it, but giving the whole
manual a read is very useful for new users of Julia.
Message has been deleted
Yichao Yu
May 30, 2016, 2:23:22 PM5/30/16
to Julia Users
On Mon, May 30, 2016 at 2:09 PM, Ford Ox <ford...@gmail.com> wrote:
> Yeah I have read it. Multiple times, since I forget things and I still don't
> remember all the things.
>
> So basically the difference is that bitwise operators are functions. That
> means its arguments get evaluated before they are passed in. That also
> means, that if that function would be inlined, && would be same as &
> because:
No. function inlining is a pure optimization that doesn't affect the
schematics of the program at all.
>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox
> is, but I guess it is something like
> &(x::Bool, y::Bool) = x && y
They do have similar effect.
> so if & would be inlined before x, y are evaluated, than && and & would have
> identical meaning ( for booleans ), right?
No. inlining is irrelevant.
>
> I was trying to achieve that with @generated, but it didn't work.
> function x()
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> @generated and_gen(x::Bool, y::Bool)
> return :(x && y)
> end
>
> and_gen(y(), x())
>
>> y
>>
>> x
>>
>> false
>
>
> Which is kinda weird, since x and y always returns Bool, so @generated
> should know types of x() and y() before their evaluation.
> and_gen(y()::Bool, x()::Bool) # also doesn't work
> Yeah I have read it. Multiple times, since I forget things and I still don't
> remember all the things.
>
> So basically the difference is that bitwise operators are functions. That
> means its arguments get evaluated before they are passed in. That also
> means, that if that function would be inlined, && would be same as &
> because:
No. function inlining is a pure optimization that doesn't affect the
schematics of the program at all.
>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox
> is, but I guess it is something like
> &(x::Bool, y::Bool) = x && y
They do have similar effect.
> so if & would be inlined before x, y are evaluated, than && and & would have
> identical meaning ( for booleans ), right?
No. inlining is irrelevant.
>
> I was trying to achieve that with @generated, but it didn't work.
> function x()
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> @generated and_gen(x::Bool, y::Bool)
> return :(x && y)
> end
>
> and_gen(y(), x())
>
>> y
>>
>> x
>>
>> false
>
>
> Which is kinda weird, since x and y always returns Bool, so @generated
> should know types of x() and y() before their evaluation.
> and_gen(y()::Bool, x()::Bool) # also doesn't work
Ford Ox
May 30, 2016, 2:25:04 PM5/30/16
to julia-users
Yeah I have read it. Multiple times, since I forget things and I still don't remember all the things.
So basically the difference is that bitwise operators are functions. That means its arguments get evaluated before they are passed in. That also means, that if that function would be inlined, && would be same as & because:
So basically the difference is that bitwise operators are functions. That means its arguments get evaluated before they are passed in. That also means, that if that function would be inlined, && would be same as & because:
&(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
&(x::Bool, y::Bool) = x && yso
if & would be inlined before x, y are evaluated, than &&
and & would have identical meaning ( for booleans ), right?
Something like
function x()
println("x")
true
end
function y()
println("y")
false
end
@generated_inline and_gen(x::Bool, y::Bool)Yichao Yu
May 30, 2016, 2:32:35 PM5/30/16
to Julia Users
value, not the function. It doesn't matter for what you want to do
though.
Tamas Papp
May 30, 2016, 2:34:46 PM5/30/16
to julia...@googlegroups.com
Don't get sidetracked by the implementation. Also, inlining has nothing
to do with it.
& is a function, && is a control flow construct. The only way you could
replicate && and || is with a macro, such that
a && b
would get expanded to something like
if a
b
else
false
end
But of course syntax restricts you from doing that (macros start with
@), so you have them in Julia as primitives.
Best,
Tamas
On Mon, May 30 2016, Ford Ox wrote:
to do with it.
& is a function, && is a control flow construct. The only way you could
replicate && and || is with a macro, such that
a && b
would get expanded to something like
if a
b
else
false
end
But of course syntax restricts you from doing that (macros start with
@), so you have them in Julia as primitives.
Best,
Tamas
On Mon, May 30 2016, Ford Ox wrote:
> Yeah I have read it. Multiple times, since I forget things and I still
> don't remember all the things.
>
> So basically the difference is that bitwise operators are functions. That
> means its arguments get evaluated before they are passed in. That also
> means, that if that function would be inlined, && would be same as &
> because:
>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox
> is, but I guess it is something like
> &(x::Bool, y::Bool) = x && y
> so if & would be inlined before x, y are evaluated, than && and & would
> have identical meaning ( for booleans ), right?
>
> don't remember all the things.
>
> So basically the difference is that bitwise operators are functions. That
> means its arguments get evaluated before they are passed in. That also
> means, that if that function would be inlined, && would be same as &
> because:
>
> &(x::Bool, y::Bool) = box(Bool,and_int(unbox(Bool,x),unbox(Bool,y)))
> I dont really understand that function, since I dont know what box, unbox
> is, but I guess it is something like
> &(x::Bool, y::Bool) = x && y
> so if & would be inlined before x, y are evaluated, than && and & would
> have identical meaning ( for booleans ), right?
>
> I was trying to achieve that with @generated, but it didn't work.
> function x()
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> println("x")
> true
> end
> function y()
> println("y")
> false
> end
> @generated and_gen(x::Bool, y::Bool)
> return :(x && y)
> end
>
> and_gen(y(), x())
>
> end
>
> and_gen(y(), x())
>
> y
>>
> x
>>
> false
>>
>
> Which is kinda weird, since x and y always returns Bool, so @generated
> should know types of x() and y() before their evaluation.
> and_gen(y()::Bool, x()::Bool) # also doesn't work
>
>
>
>
> On Monday, May 30, 2016 at 1:19:05 PM UTC+2, Tamas Papp wrote:
>>
>>
> x
>>
> false
>>
>
> Which is kinda weird, since x and y always returns Bool, so @generated
> should know types of x() and y() before their evaluation.
> and_gen(y()::Bool, x()::Bool) # also doesn't work
>
>
>
>
> On Monday, May 30, 2016 at 1:19:05 PM UTC+2, Tamas Papp wrote:
>>
Ford Ox
May 31, 2016, 12:46:20 PM5/31/16
to julia-users
As a side note.
Are add_int(), box() and unbox() implemented in c?
I was trying to find their declaration but was not successful.
Are add_int(), box() and unbox() implemented in c?
I was trying to find their declaration but was not successful.
Kristoffer Carlsson
May 31, 2016, 2:24:43 PM5/31/16
to julia-users
Ford Ox
May 31, 2016, 2:40:25 PM5/31/16
to julia-users
On Tuesday, May 31, 2016 at 8:24:43 PM UTC+2, Kristoffer Carlsson wrote:
https://youtu.be/dK3zRXhrFZY?t=600
Thanks!
Reply all
Reply to author
Forward
0 new messages