short circuit operators
Stefanie Ertheld
result is: false
b) true || true && false
result is: true
Why is a false while b is true?!
Thanks in advance,
Stefanie
Roedy Green
<Dulid...@web.de> wrote, quoted or indirectly quoted someone who
said :
>a) true | true && false
>result is: false
>
>b) true || true && false
>result is: true
>
>Why is a false while b is true?!
see http://mindprod.com/jgloss/precedence.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Arne Vajhøj
> a) true | true && false
> result is: false
>
> b) true || true && false
> result is: true
>
> Why is a false while b is true?!
They work that way.
But read:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc9.html#331
Arne
Stefanie Ertheld
> Stefanie Ertheld wrote:
>> a) true | true && false
>> result is: false
>>
>> b) true || true && false
>> result is: true
>>
>> Why is a false while b is true?!
>
> They work that way.
Well, I guess I realized that part. However, I am still interested to
know exactly why that is so - what's the rule behind this?
Lew
The rule is operator precedence, as Roedy Green said.
| is higher than && is higher than ||.
a) true | true && false
true && false
false
b) true || true && false
true || false
true
--
Lew
Lew
> Stefanie Ertheld <Dulid...@web.de> writes:
>> Well, I guess I realized that part. However, I am still interested to
>> know exactly why that is so - what's the rule behind this?
>
> de.comp.lang.java three hours ago? Quote:
>
> From: Patrick Roemer <sang...@netcologne.de>
> Newsgroups: de.comp.lang.java
> Subject: Re: short cicuit auswertung
> Date: Sun, 24 Feb 2008 15:44:18 +0100
> Message-ID: <fprvs2$sdd$1...@newsreader2.netcologne.de>
> [...]
>
> Responding to Stefanie Ertheld:
>
> > a) true | true && false
> >
> > b) true || true && false
> >
> > Warum? D.h. warum erhält man in a) false, während man bei b) true erhält?
>
> Praezedenz: '|' > '&&' > '||'
>
> Viele Gruesse,
> Patrick
What? Multi-posting? Usenet Gods forfend!
--
Lew
Arne Vajhøj
For each programming language the inventors sit down and
decide on an order of operator precedence.
From the practical point of view, then the order is as it is.
If you have a philosophical interest in why they made the decisions,
then you will need to track down some of the people at SUN that
made those decisions back in 1991.
And as I tried to explain then you should write code, so that
it is also readable for those that has not memorized the operator
precedence order.
Arne
Stefanie Ertheld
It just says that "|" has higher precedence than "&&", which has higher
precedence than "||".
Well I realized that before I wrote my question. I would be interested
in MORE details - why is that so? There's always a reason - without a
reason a rule is quite hard to remember...
Also, I guess the entire rule must be something like:
& -> ^ ->| -> &&-> ||
Well I guess I know why an "AND" has higher precedence than an "OR" -
because that's the rule logical operators are defined in general (even
though for this I still don't completly know the reason, but maybe there
is none).
However, the question is probably more "why are non-short circuit
operators evaluated before short circuit operators?!
I guess, yet I don't know, that this is because the idea behind the
short circuit operators is to be as efficent - a.k.a. - as fast as
possible terminating as possible - and I guess to achieve this,
everything that comes before a short circuit operator must be evaluated
first - if all this evaluates to false, and we have a "&&", there's no
need to evaluate the rest of the statement.
a & b & c | d && f
if this: a & b & c | d evaluates to false, the rest of the statement
doesn't have to be evaluated anymore.
So maybe that's the reason it is as it is?
Well, I still don't really know...
Thanks,
Stefanie
Joshua Cranmer
> Well I guess I know why an "AND" has higher precedence than an "OR" -
> because that's the rule logical operators are defined in general (even
> though for this I still don't completly know the reason, but maybe there
> is none).
Boolean AND is roughly equivalent to algebraic multiplication and
boolean OR is roughly equivalent to algebraic addition (aside:
bitwise-or and bitwise-xor have equal precedence). Multiplication has a
higher precedence than addition, so their boolean correspondents have
the same precedence. I am also guessing that (a AND b) OR (c AND d) is
slightly more prevalent than (a OR b) AND (c OR d), but I don't think
that consideration entered into play when deciding precedence.
> However, the question is probably more "why are non-short circuit
> operators evaluated before short circuit operators?!
The short circuit operators are designed for a usage like so:
if (a == b && c == d)
The bitwise operators would be designed to have a higher precedence than
conditional evaluation, and conditional evaluation are designed to have
a higher precedence than short-circuit operators, so the bitwise
operators have higher precedence by the transitive property.
> I guess, yet I don't know, that this is because the idea behind the
> short circuit operators is to be as efficent - a.k.a. - as fast as
> possible terminating as possible - and I guess to achieve this,
> everything that comes before a short circuit operator must be evaluated
> first - if all this evaluates to false, and we have a "&&", there's no
> need to evaluate the rest of the statement.
The strongest reason for short-circuit evaluation, I believe, is to
permit constructs like
if (<A is not in an error state> && <some result using A>)
or
if (<A is in an error state> || <some operation using A failed>)
The bitwise operators, as their name suggests, are designed to be
manipulating bits on one of the operands, so short-circuiting is a poor
idea.
> Well, I still don't really know...
Hopefully, I helped...
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Hendrik Maryns
This remarkable use of the word ‘forfend’ has given you eternal fame on
Wiktionary: http://en.wiktionary.org/wiki/forfend
Cheers, H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Lew
>> What? Multi-posting? Usenet Gods forfend!
Hendrik Maryns wrote:
> This remarkable use of the word ‘forfend’ has given you eternal fame on
> Wiktionary: http://en.wiktionary.org/wiki/forfend
Ummm - thanks, er, I think.
There's nothing very remarkable in that usage, however. "Gods forfend!" is
/the/ classic use of the word "forfend", and "<fill-in-the-domain> gods
forfend!" a common expression.
I do like seeing the adjuration against multi-posting gain publicity, though.
--
Lew
Thomas.a...@nasa.gov
> Stefanie Ertheld wrote:
> > Well I guess I know why an "AND" has higher precedence than an "OR" -
> > because that's the rule logical operators are defined in general (even
> > though for this I still don't completly know the reason, but maybe there
> > is none).
>
> Boolean AND is roughly equivalent to algebraic multiplication and
> boolean OR is roughly equivalent to algebraic addition (aside:
> bitwise-or and bitwise-xor have equal precedence). Multiplication has a
> higher precedence than addition, so their boolean correspondents have
> the same precedence. I am also guessing that (a AND b) OR (c AND d) is
> slightly more prevalent than (a OR b) AND (c OR d), but I don't think
> that consideration entered into play when deciding precedence.
>
compelling. However in SQL the logical operator AND has precedence
over OR. So for whatever reason this precedence has rather long
precedent - back to the 70's or so if not further.
Regards,
Tom Mcglynn
Roedy Green
>Well, I guess I realized that part. However, I am still interested to
>know exactly why that is so - what's the rule behind this?
see http://mindprod.com/jgloss/precedenence.html
Lars Enderin
> On Sun, 24 Feb 2008 18:40:11 +0100, Stefanie Ertheld
> <Dulid...@web.de> wrote, quoted or indirectly quoted someone who
> said :
>
>> Well, I guess I realized that part. However, I am still interested to
>> know exactly why that is so - what's the rule behind this?
>
> see http://mindprod.com/jgloss/precedenence.html
>
Lars Enderin
In the page reached with http://mindprod.com/jgloss/precedence.html you
repeat int (a) in the explanation of the ternary operator ?:.
Lew
> To me the analogy with multiplication and addition doesn't seem very
> compelling. However in SQL the logical operator AND has precedence
> over OR. So for whatever reason this precedence has rather long
> precedent - back to the 70's or so if not further.
It's precisely identical mathematically, hence the "analogy".
1 * 1 = 1
1 * 0 = 0
0 * 1 = 0
0 * 0 = 0
Hmm, looks like AND.
1 + 1 = 0 (if you drop the overflow bit, as most processors do)
1 + 0 = 1
0 + 1 = 1
0 + 0 = 0
Hmm, looks like XOR.
If you keep the overflow, and count 0 as equivalent to FALSE, any non-zero
equivalent to TRUE, as, say, C does, then '+' looks like OR.
"Compelling" enough for you?
--
Lew
Nigel Wade
> On Feb 24, 7:28 pm, Joshua Cranmer <Pidgeo...@verizon.invalid> wrote:
>> Stefanie Ertheld wrote:
>> > Well I guess I know why an "AND" has higher precedence than an "OR" -
>> > because that's the rule logical operators are defined in general (even
>> > though for this I still don't completly know the reason, but maybe there
>> > is none).
>>
>> Boolean AND is roughly equivalent to algebraic multiplication and
>> boolean OR is roughly equivalent to algebraic addition (aside:
>> bitwise-or and bitwise-xor have equal precedence). Multiplication has a
>> higher precedence than addition, so their boolean correspondents have
>> the same precedence. I am also guessing that (a AND b) OR (c AND d) is
>> slightly more prevalent than (a OR b) AND (c OR d), but I don't think
>> that consideration entered into play when deciding precedence.
>>
> To me the analogy with multiplication and addition doesn't seem very
> compelling.
I guess you haven't studied boolean algebra then?
> However in SQL the logical operator AND has precedence
> over OR.
If the only reason was "because SQL does it", then it wouldn't be very
compelling to me either.
> So for whatever reason this precedence has rather long
> precedent - back to the 70's or so if not further.
A little further back, to Boole himself in the mid C19th.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : n...@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
k-e-n
There are some languages which are built on a single core concept from
which most if not all of the language features can be derived or at
least understood, Java is not one of these languages, nor are most of
the languages in general widespread use today.
Other languages you may want to look at are RUBY - which attempts an
'english - like' grammatical structure for its components.
I recommend this rather unorthodox but very readable guide to Ruby
http://poignantguide.net/ruby/
SMALLTALK an 'ancient' object-oriented language (but still in use)
which takes the approach that 'everything is an object' - even the
source code.
J http://www.jsoftware.com/ a complex but highly efficient language
with a very strict / formal grammatical system.
Lisp - everything is a list & everything can be done by recursion.
Also as I mention in the list below it is simply not good practice to
mix Bitwise and Boolean operators in the same expression, just because
you can, does not mean you should.
To summarize the other responses & to add my own:
1. Accept that it is this way because that is how the language is
defined,
etymology (the history and evolution of words) is an interesting
topic but best applied to human languages rather than computer
programming languages.
2. Read the Java Language Specification: http://java.sun.com/docs/books/jls/index.html
- available as HTML or PDF see section 15.22
3. And I think most important of all: Do Not Mix Boolean Operators and
Bitwise Operators in the Same Expression.
Programming languages are tools to get a job done.
If you want to do this, learn the rules of the language and use it
effectively.
If you want to understand boolean logic or computer language design
you need to study computer science (somewhere that teaches you more
than just how to program).
Patricia Shanahan
...
> Also as I mention in the list below it is simply not good practice to
> mix Bitwise and Boolean operators in the same expression, just because
> you can, does not mean you should.
> 3. And I think most important of all: Do Not Mix Boolean Operators and
> Bitwise Operators in the Same Expression.
Note that "|" and "&" with boolean operands, such as true and false, are
not bitwise operations. They are boolean operations without
short-circuiting, so that the right hand side is evaluated regardless of
the left hand side value. They are only bitwise operators if applied to
integer operands.
What is wrong with mixing bitwise and boolean operators in the same
expression? Suppose I want to do something if a particular bit is on in
either of two ints:
if( (intA & mask) || (intB & mask) )
seems reasonable to me, but it definitely mixes bitwise and boolean
operations. How would you do it?
Patricia
Joshua Cranmer
> 3. And I think most important of all: Do Not Mix Boolean Operators and
> Bitwise Operators in the Same Expression.
I think that a better guideline would be "Use parenthesis unless the
precedence is obvious". For example, everyone should know what a + b * c
is, or the precedence of a == b || c == d, but a + b | c is not at all
obvious.
Eric Sosman
First, I'd fix the "operator || cannot be applied
to int,int" error, which would get me to
if( (intA & mask) != 0 || (intB & mask) != 0 )
... and then for this particular case I'd rearrange to
if ( ((intA | intB) & mask) != 0 )
... except that if intB were actually expensiveMethod()
I'd leave well enough alone.
Patricia Shanahan
> Patricia Shanahan wrote:
>> k-e-n wrote:
>> ...
>>> Also as I mention in the list below it is simply not good practice to
>>> mix Bitwise and Boolean operators in the same expression, just because
>>> you can, does not mean you should.
>> ...
>>> 3. And I think most important of all: Do Not Mix Boolean Operators and
>>> Bitwise Operators in the Same Expression.
>>
>> Note that "|" and "&" with boolean operands, such as true and false, are
>> not bitwise operations. They are boolean operations without
>> short-circuiting, so that the right hand side is evaluated regardless of
>> the left hand side value. They are only bitwise operators if applied to
>> integer operands.
>>
>> What is wrong with mixing bitwise and boolean operators in the same
>> expression? Suppose I want to do something if a particular bit is on in
>> either of two ints:
>>
>> if( (intA & mask) || (intB & mask) )
>>
>> seems reasonable to me, but it definitely mixes bitwise and boolean
>> operations. How would you do it?
>
> First, I'd fix the "operator || cannot be applied
> to int,int" error, which would get me to
>
> if( (intA & mask) != 0 || (intB & mask) != 0 )
Sorry, that is what I should have written.
Patricia
k-e-n
I would do it as you have done and as Joshua Cranmer suggests, use
parenthesis to make the precedence and more specifically your intent
clear.
To a programmer the parenthesis are sufficient advice, to someone who
seems not to understand precedence or perhaps more specifically wants
to know why the rule(s)
exists and what is the meta-rule behind that, I felt something
stronger was required.
Did you have any problem with any other parts of my comment? I have no
wish to cause offense or create any controversy.
Arne Vajhøj
> Also as I mention in the list below it is simply not good practice to
> mix Bitwise and Boolean operators in the same expression, just because
> you can, does not mean you should.
The test should reflect the functionality you want. If the functionality
requires mixing shortcircuit and non-shortcircuit operators, then there
is not much to do about it.
Arne
Lew
> Precendence of operators does not imply chronological sequence
> of evaluation.
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.7.3>
> Java programming language implementations must respect the order of evaluation
> as indicated explicitly by parentheses and implicitly by operator precedence.
It's one of the ways in which Java explicitly went in a different direction
from its forebears, up there with fixing the domains of primitive types.
--
Lew