Boolean Arithmetics

[Martin Hill]

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
> 
> ================================================================================
> Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
>    11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
> ================================================================================