<4046F003.106-at-dial.pipex.com>
Subject: Re: Boolean Arithmetics
Date: Thu, 4 Mar 2004 11:10:26 -0000
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: X-Scanned-By: MIMEDefang 2.35
I suppose the only reason it would matter was if there were side effects
from evaluating any of the operands, e.g. if executing foo() made a
difference to the result of bar() then
bar() OR bar() OR foo()
could give a different answer to
bar() OR (bar() OR foo())
But none of us would write such dodgy code would we?
John Taylor +44 (0) 131 668 8328Astrogrid Java Developer
> Maybe it's a discipline thing. My logic lessons came from electronics,
> where the implementation might take two inputs but might not. The
> written representation has two operators around AND only because of the
> way we write things down.
>
> Mathematically, and from the point of view of the searches we want to
> carry out, we are talking about Unions and Intersections aren't we? I'm
> sure these are not defined as applying to pairs of sets only... At
> least I seem to remember some pretty complicated Venn diagrams...
>
> Anyway: it's an arbitrary, artificial limitation we are putting on the
> language. Maybe I am the only one on this list who is going to be
> writing interpreters - but it would make life easier if such
> interpreters could assume that explicit precidence implied user-imposed
> optimisation, and if no explicit precidence is given, the interpreter
> can carry out it's own optimisation.
>
> I'm still interested in why folks *want* this limitation imposed on the
> language...
>
> Cheers,
>
> Martin
>
>
> Francois Ochsenbein wrote:
>
> > Martin,
> >
> > Looks like the boolean arithmetics differs in the UK from what
> > it is in other countries ??? Yes the boolean operators AND(&) and OR(|)
> > are associating 2 elements taken from the boolean set (true false),
> > and have the properties of
> > - associativity (a&b)&c = a&(b&c) = a&b&c ; similary for OR
> > - commutativy a&b = b&a a|b = b|a
> > - distributivity a&(b|c) = (a&b) | (a&c)
> > exactly like the multiplication and addition applied on the set
> > (0,1) representing (false, true)
> >
> >
> >>Ray Plante wrote:
> >>
> >>
> >>>With regards to the cardinality issue, I am against the idea of
allowing
> >>>2* for functions like add, div, and, & or. These are mathematically
> >>>defined as two-operand operations, and so our XML model should reflect
> >>>this. The fact that it raises the issue of order of operation is a
good
> >>>thing; we must deal with this.
> >>
> >>On the contrary, AND and OR are *not*, logically, defined as two-operand
> >>operations. Nor is it system dependent. The order of operation is
> >>purely up to the end-interpreter and has nothing to do with the language
> >>we use to specify the operations. We lose easy optimisation if we
> >>impose such restrictions - especially if *we* start imposing an
> >>arbitrary left-right evaluation.
> >>
> >>I don't want to get too hung up on this, because I am much happier with
> >>this version than previous; but I am intrigued as to why people are hung
> >>up on restricting it to pairwise?
> >>
> >>Cheers,
> >>
> >>Martin
> >
> >