short circuit operators

[Stefanie Ertheld]

a) true | true && false
result is: false

b) true || true && false
result is: true

Why is a false while b is true?!

Thanks in advance,

Stefanie

 

[Roedy Green]

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

 

[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]

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?

 

[Stefan Ram]

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?

What do you make of the answer that was given to you in
de.comp.lang.java three hours ago? Quote:

From: Patrick Roemer <[email protected]>
Newsgroups: de.comp.lang.java
Subject: Re: short cicuit auswertung
Date: Sun, 24 Feb 2008 15:44:18 +0100
Message-ID: <[email protected]>
[...]

Responding to Stefanie Ertheld:

> a) true | true && false
> ergibt: false
>
> b) true || true && false
> ergibt: true
>
> Warum? D.h. warum erhält man in a) false, während man bei b) true erhält?

Praezedenz: '|' > '&&' > '||'

Viele Gruesse,
Patrick

 

[Lew]

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?

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]

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?

What do you make of the answer that was given to you in
de.comp.lang.java three hours ago? Quote:

From: Patrick Roemer <[email protected]>
Newsgroups: de.comp.lang.java
Subject: Re: short cicuit auswertung
Date: Sun, 24 Feb 2008 15:44:18 +0100
Message-ID: <[email protected]>
[...]

Responding to Stefanie Ertheld:

a) true | true && false
ergibt: false

b) true || true && false
ergibt: true

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!

 

[Arne Vajhøj]

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?

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]

Well, in my eyes the answer helps a bit, but not really -
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...

 

[Hendrik Maryns]

Lew schreef:

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?

What do you make of the answer that was given to you in
de.comp.lang.java three hours ago? Quote:

From: Patrick Roemer <[email protected]>
Newsgroups: de.comp.lang.java
Subject: Re: short cicuit auswertung
Date: Sun, 24 Feb 2008 15:44:18 +0100
Message-ID: <[email protected]>
[...]
Responding to Stefanie Ertheld:

a) true | true && false
ergibt: false

b) true || true && false
ergibt: true

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!

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHwrqCe+7xMGD3itQRAn9kAJ0SknAhnzAibNCBEuRODtN5/UIDgwCeIkKT
DUyLhgBDJYo2vGRCnt0DqN0=
=YAWU
-----END PGP SIGNATURE-----

 

[Lew]

Lew schreef:

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.

 

[Thomas.a.mcglynn]

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. 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]

Roedy Green skrev:

see http://mindprod.com/jgloss/precedenence.html

Sloppy spelling of precedence.

 

[Lars Enderin]

Lars Enderin skrev:

Roedy Green skrev:
Sloppy spelling of precedence.

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?

 

[Nigel Wade]

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.

 

[k-e-n]

a) true | true && false
result is: false

b) true || true && false
result is: true

Why is a false while b is true?!

Thanks in advance,

Stefanie

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]

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?

Patricia