Bring back the XOR

[vgermrk]

Since the preparser replaces "^" with "**" (which is good!),
i want a way to access the python-buildin-XOR again.

I suggested in IRC that the preparser should also replace "xor" with
"^",
so that one can do "5 xor 3".
But since i did not convince everybody (on IRC), let's discuss here
about it.

So what do you think?

-vgermrk-

[Stephen Forrest]

What are the main counterarguments?  I expect the main issue is with avoiding excessive divergence from Python syntax, though I think this is a special case as Sage has already overridden Python's native xor binary operator.  Are there operator precedence issues here?

Having "xor" as a binary operator does fit with the native "and" and "or", and Sage programmers are probably more likely than random programmers to want to make use of "xor" and "implies" in their conditional logic.

For the record, Maple has all of "and", "or", "xor", and "implies" as binary operators.

Steve

[David Joyner]

Another solution (avoiding the preparer) is to simply define

sage: def xor(a,b): return eval("%s^%s"%(a,b))
....:
sage: xor(1,0)
1
sage: xor(1,1)
0

which mimics the native Python behavior:

Python 2.5.1 (r251:54863, Oct 5 2007, 13:50:07)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1^0
1
>>> 1^1
0

[David Roe]

Note that the function that is called by "^" is __xor__.  So you can already do a.__xor__(b).  If you want to write the function that David describes, calling a.__xor__(b) is better than using eval.
David

[John Cremona]

I don't suppose ^^ (for xor) will have much support....

John

--
John Cremona

[Robert Bradshaw]

"and" and "or" in python are not binary operators, they are control
flow keywords. (Specifically, they short circuit).

I think we should have something. 10r is a "raw" python integer, 2.3r
a python float, but ^r looks like "raising to the r." ^^ seems like
the most reasonable syntax.

- Robert

[Carl Witty]

On Mar 10, 4:24 am, "Stephen Forrest" <stephen.forr...@gmail.com>
wrote:

I kind of liked " xor " until you said this...

"and" and "or" are control flow operators, and work on booleans. We
want an xor that is a bitwise operation on integers; I now think that
using the word "xor" would be confusing.

(Note that Maple's xor operator works on booleans, and gives errors on
integers.)

Note that "^^" does have the same problem: in C/C++/etc., |,&,^ are
bitwise operators and ||,&& are boolean operators; somebody looking at
^^ could think that it's supposed to be a boolean operator. Even so,
I prefer "^^" to "xor".

Carl

[William Stein]

+1
Unless somebody thinks of something better, I like ^^ as well.

William

[boo...@u.washington.edu]

I don't like ^^. Since ~ is a unary operator, we could safely use it as a binary operator, as well. I don't really like a~b to denote xor... but I like it better than ^^.

[John Cremona]

I was only half serious when I suggested ^^, and was surprised that
others quote liked it. But I *really* don't like ~. The only similar
symbol ever used in logic means "not" (negation) so this is completely
unintuitive.

John

--
John Cremona

[Robert Bradshaw]

On Mar 10, 2008, at 12:40 PM, John Cremona wrote:

> I was only half serious when I suggested ^^, and was surprised that
> others quote liked it.

I don't think it's that pretty, but I think it's the best of many
other bad alternatives, and it at least somewhat ties in to the
python choice of xor. Also, I don't see xor being used very often,
and so is an allowable wart to let 2^5 = 32 (which is used all over).

> But I *really* don't like ~. The only similar
> symbol ever used in logic means "not" (negation) so this is completely
> unintuitive.

I would echo this. On another note, a~b is much a harder to preparse
as it must detect whether ~ is being used as a binary or unary
operation.

[vgermrk]

It's now #2569: http://trac.sagemath.org/sage_trac/ticket/2569