sympy.And, &: sympy.Or |

[Robert]

Hello Sympy group,

As usual I appreciate your time, you've been very helpful so far with
our upgrade. (We've moved to a newer version of sympy).

One thing that I found recently is that & and | seem to no longer be
supported. I see there is a ticket for this
http://code.google.com/p/sympy/issues/detail?id=3105&q=%7C&sort=-id&colspec=ID
Type Status Priority Milestone Reporter Summary Stars

the ticket seems to mention that And doesn't do anything meaningful.
However, it appears to work upon testing:

import sympy
p = sympy.Symbol('p')
q = sympy.Symbol('q')

(p>10) & (q>10) fails with TypeError: unsupported operand type(s) for
&: 'StrictInequality' and 'StrictInequality'

however, sympy.And appears to work:
temp = sympy.And(p>10, q>10)
temp.subs(dict(p=12, q=30))
True

Is there any work around currently?

[Robert]

Another argument for reimplementing the behavior is that using
sympy.And/sympy.Or when & and | would mean the same thing is difficult
to justify.

Thoughts are appreciated,
Thanks,
Rob

On May 2, 9:42 am, Robert <phub...@gmail.com> wrote:
> Hello Sympy group,
>
> As usual I appreciate your time, you've been very helpful so far with
> our upgrade. (We've moved to a newer version of sympy).
>
> One thing that I found recently is that & and | seem to no longer be

> supported. I see there is a ticket for thishttp://code.google.com/p/sympy/issues/detail?id=3105&q=%7C&sort=-id&c...

[Joachim Durchholz]

Am 02.05.2012 16:42, schrieb Robert:
> http://code.google.com/p/sympy/issues/detail?id=3105&q=%7C&sort=-id&colspec=ID

>
> the ticket seems to mention that And doesn't do anything meaningful.

No, Ronan says that a specific use case does not work as we'd like it to.
In this case, the problem is that boolean values, boolean simplification
and assumptions all have overlaps, and it's not clear how the system
should work in general. We know a lot of things that aren't quite right,
but we don't know for sure how a correct solution should work.

[Robert]

I see yes the specific case is a somewhat different story. Regardless
it does make sense to map & to And and | to OR? As an alternative is
there any nice way to override the behavior of & and | in sympy?

Thanks,
Rob

On May 2, 3:09 pm, Joachim Durchholz <j...@durchholz.org> wrote:
> Am 02.05.2012 16:42, schrieb Robert:
>

> >http://code.google.com/p/sympy/issues/detail?id=3105&q=%7C&sort=-id&c...

[Aaron Meurer]

Hi.

There are two basic issues here.

The first issue is that Relational is not clearly a boolean or not a
boolean. It acts like a boolean sometimes, as you saw, in that it
reduces to True or False in some cases. But in other ways, it does
not. http://code.google.com/p/sympy/issues/detail?id=1887 is the key
issue here.

Actually, Booleans are kind of a mess in SymPy. The only reason that
x | y => And(x, y) works is that Symbol is a subclass of Boolean. But
this (at least to me) is wrong, because Symbol represents an
indeterminate complex number. We really should have a separate
BooleanSymbol class that represents an indeterminate boolean. We
could make Symbol coerce to BooleanSymbol automatically with | and &
(assuming it has no assumptions on it that makes it necessarily not a
boolean) for user convenience, but at the core, they should be
different. So actually, Symbol has the exact same problem as
Relational from issue 1887.

The second issue is that And, Or, etc. do not do type checking on
their arguments, which is why And(x < y, y < z) works, even though x <
y is not a Boolean. It also allows nonsensical things like

In [873]: print And(x**2, x)
And(x, x**2)

We could fix this, and then relationals would not work in boolean
classes at all (until 1887 was fixed). This would be a regression,
however, because as you noted, relationals do (sort of) work in the
logic classes.

Practically, you can fix this problem in one of two ways. The first
way is to make Relational a subclass of Boolean, i.e., apply this
patch:

diff --git a/sympy/core/relational.py b/sympy/core/relational.py
index 9e0ea3d..931637a 100644
--- a/sympy/core/relational.py
+++ b/sympy/core/relational.py
@@ -3,6 +3,8 @@
from evalf import EvalfMixin
from sympify import _sympify

+from sympy.logic.boolalg import Boolean
+
__all__ = (
'Rel', 'Eq', 'Ne', 'Lt', 'Le', 'Gt', 'Ge',
'Relational', 'Equality', 'Unequality', 'StrictLessThan', 'LessThan',
@@ -122,7 +124,7 @@ def Ge(a, b):
"""
return Relational(a,b,'>=')

-class Relational(Expr, EvalfMixin):
+class Relational(Boolean, Expr, EvalfMixin):

__slots__ = []

This might break some things (though I ran the tests, and everything
passed, so maybe not).

The other way is to just add the relevant methods to Relational. This
way is ideal if you don't want to modify the code, because they can be
hooked at runtime. So if you add something like

from sympy.logic.boolalg import Relational
Relational.__and__ = lambda self, other: And(self, other)
Relational.__or__ = lambda self, other: Or(self, other)
...

at the top of whatever file you want to use (x > y) & (y < z) syntax,
it will work.

Finally, I want to ask if people think the first option (making
Relational subclass from Boolean) would be an acceptable workaround to
push into SymPy until we can get issue 1887 pushed in. If you look at
the code, the class Boolean just defines the __methods__ for logic
operations, so it essentially would do nothing but fix this
regression. Since we are already doing the same thing for Symbol, I
don't think it is too bad (at least no worse than what we are already
doing). This would also allow us to add type checking to Add, Or,
etc., so that And(x, x**2) stops working.

If so, I'll write up some tests and submit it as a pull request.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>

[Joachim Durchholz]

Am 02.05.2012 23:39, schrieb Aaron Meurer:
> Finally, I want to ask if people think the first option (making
> Relational subclass from Boolean) would be an acceptable workaround to
> push into SymPy until we can get issue 1887 pushed in.

I can't really judge because I have no idea of the ramifications.