OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

# office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: query / comment on XOR() - let's change XOR

• From: "David A. Wheeler" <dwheeler@dwheeler.com>
• To: office-formula@lists.oasis-open.org
• Date: Tue, 13 Feb 2007 13:31:07 -0500 (EST)

```I agree with Brad Hards and Eike, we should change the definition of XOR.  And my thanks to Brad Hards for telling us this!!

Eike, will you do that please?   You may as well change {Logical L}* to {Logical L}+,
and fix the extraneous yellow line.

Details below.

Brad Hards (08 Feb 2007 16:59:26 +1100):
> The 20070201 version of the openformula spec contains a description of XOR in 6.13.7.
> The problem I have is that my expectation for XOR is that the output is true
> if an odd number of inputs are true, and false if an even number of inputs
> are true (from binary logic).
> Should "=XOR(TRUE(),TRUE(),TRUE())" return true (my expectation) or false (per
> the current specification)?

> Brad gave a valid objection on the comment list.
>
> Adhoc I'd also expect a TRUE in the case of =XOR(TRUE();TRUE();TRUE()).
> It depends though whether =XOR(1;1;1) should be identical to
> ((1 XOR 1) XOR 1) or exactly one and only one out of a list must be TRUE
> for this function to return true.
>
> Opinions? Gnumeric returns TRUE for XOR(1;1;1).

I've looked around, and all sources agree with Brad.

I've done a straw poll of co-workers, and all agree with Brad and Eike's expectation.

Wolfram (http://mathworld.wolfram.com/XOR.html) says:
"For multiple arguments, XOR is defined to be true if an odd number of its arguments are true, and false otherwise. This definition is quite common in computer science, where XOR is usually thought of as addition modulo 2. In this context, it arises in polynomial algebra modulo 2, arithmetic circuits with a full adder, and in parity generating or checking. While this means that the multiargument "XOR" can no longer be thought of as "the exclusive OR" operation, this form is rarely used in mathematical logic and so does not cause very much confusion. The XOR operation is associative, so a xor (b xor c) is the same as (a xor b) xor c. Computation of the multiargument XOR requires evaluation of all its arguments to determine the truth value, and hence there is no "lazy" special evaluation form (as there is for AND and OR)."

Common Lisp does the same thing; it say this at:
http://www.supelec.fr/docs/cltl/clm/node131.html
And when I tried "(logxor 1 1 1)" on the clisp implementation of Common Lisp it returned True.

Brad: Thanks SO MUCH for letting us know.  That's GREAT.

>
> Regarding the line mentioning I think that was meant as a pointer to how
> the XOR function could behave similar to the OR function when no
> parameter given. The sentence before that reads "When given zero
> parameters, applications may return a Logical value or an error."
> I think that should be removed and the syntax changed to {Logical L}+
> instead of {Logical L}*. The constraints already say "Must have 1 or
> more parameters".

Agree.
--- David A. Wheeler

```

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]