Status of old/new assumptions systems

[Oscar Benjamin]

What exactly is that status of the old and new assumptions systems in
sympy? I've read a few things including
https://github.com/sympy/sympy/wiki/Assumptions but I'm still a little
confused.

Are the two systems properly independent of one another? When I use
Symbol('x', positive=True) will that positive flag be ignored when
using ask(x,...)? Actually I think I can answer that question myself:

(using master)
>>> from sympy import *
>>> x = Symbol('x', positive=True)
>>> y = Symbol('y')
>>> simplify(abs(x))
x
>>> refine(abs(x))
x
>>> simplify(abs(y))
Abs(y)
>>> refine(abs(y))
Abs(y)
>>> ask(Q.positive(x))
True
>>> ask(Q.positive(x), Q.negative(x))
True
>>> ask(Q.positive(y), Q.negative(y))
False
>>> print(ask(Q.positive(y)))
None

So it seems that the new system uses the positive attribute on x even
if it contradicts the explicit assumptions passed to ask. Presumably
then as a user I need to be disciplined in not using both systems.
Should I future-proof my own code by sticking to the new system?

But what are the plans for this in future? It seems that sympy is
about to release version 1.0 but isn't this exactly the kind of thing
that would normally be resolved before a 1.0 release?

This isn't a criticism: I'm just trying to understand where sympy's going.

--
Oscar

[Aaron Meurer]

In the released version (0.7.6.1), the systems are independent. In
master, the new assumptions (ask(), Q) read the old assumptions on
Symbols (is_positive, positive=True).

For performance purposes, this was done in a way that prevents the new
assumptions from noticing contradictions (it was added to the old ask
handler system instead of the new satask handler system). This will
hopefully change in the future, but there are some performance issues
that need to be worked out with the satask system.

For now, I would recommend using the old assumptions. However, you can
play with the new assumptions. The goal in making the new assumptions
read the old was to make this easier to do.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTAqUOVUOzUa1PfH-7m-7eMLZJrjTd9PiPsd_%3D_xEMkyg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Oscar Benjamin]

On 15 January 2016 at 15:06, Aaron Meurer <asme...@gmail.com> wrote:
>
> In the released version (0.7.6.1), the systems are independent. In
> master, the new assumptions (ask(), Q) read the old assumptions on
> Symbols (is_positive, positive=True).
>
> For performance purposes, this was done in a way that prevents the new
> assumptions from noticing contradictions (it was added to the old ask
> handler system instead of the new satask handler system). This will
> hopefully change in the future, but there are some performance issues
> that need to be worked out with the satask system.

Does this mean that there is a third (newer) assumption system?

> For now, I would recommend using the old assumptions. However, you can
> play with the new assumptions. The goal in making the new assumptions
> read the old was to make this easier to do.

But it also makes it a confusing mish-mash of the two. What's the
eventual goal here?

--
Oscar

[Aaron Meurer]

On Mon, Jan 18, 2016 at 6:32 AM, Oscar Benjamin
<oscar.j....@gmail.com> wrote:
> On 15 January 2016 at 15:06, Aaron Meurer <asme...@gmail.com> wrote:
>>
>> In the released version (0.7.6.1), the systems are independent. In
>> master, the new assumptions (ask(), Q) read the old assumptions on
>> Symbols (is_positive, positive=True).
>>
>> For performance purposes, this was done in a way that prevents the new
>> assumptions from noticing contradictions (it was added to the old ask
>> handler system instead of the new satask handler system). This will
>> hopefully change in the future, but there are some performance issues
>> that need to be worked out with the satask system.
>
> Does this mean that there is a third (newer) assumption system?

From a user point of view no. Internally, there is a newer backend to
the new assumptions (ultimately the plan is to have multiple backends
with varying degrees of performance and computational power).

>
>> For now, I would recommend using the old assumptions. However, you can
>> play with the new assumptions. The goal in making the new assumptions
>> read the old was to make this easier to do.
>
> But it also makes it a confusing mish-mash of the two. What's the
> eventual goal here?

The eventual goal is to merge the two, so that one calls the other.
Then it won't matter which one you use. It will just be a question of
which syntax you prefer. For now, we have that in one direction (the
new system calls the old).

If you only use the old assumptions, you can more or less ignore the
new system, which is what I recommend for normal usage. The new system
is still in a stage where you can play with it and see if it helps you
solve your problem, but for real world work, you should use the old
system.

There are some things that are not expressible in the old system, and
the new system also has (potentially) far more deductive power. If you
come across a problem like that you might consider looking at the new
system. But don't be surprised if things aren't actually implemented
yet (for example, the new system has the potential to make it much
easier to work with inequality based assumptions, like "assume x > y",
but none of it is actually implemented yet).

The other reason to do this is that almost none of the code in SymPy
itself uses the new assumptions; it's all still using the old
assumptions. This likely won't change until we get to a point where
the old system calls the new one (i.e., they are merged into one
system).

Aaron Meurer

>
> --
> Oscar
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTJhd5gGULjDJU1sjyrfTxS3WLOLWH-ubxN2MMuKtvuMw%40mail.gmail.com.

[Oscar Benjamin]

On 18 January 2016 at 20:47, Aaron Meurer <asme...@gmail.com> wrote:
>>> For now, I would recommend using the old assumptions. However, you can
>>> play with the new assumptions. The goal in making the new assumptions
>>> read the old was to make this easier to do.
>>
>> But it also makes it a confusing mish-mash of the two. What's the
>> eventual goal here?
>
> The eventual goal is to merge the two, so that one calls the other.
> Then it won't matter which one you use. It will just be a question of
> which syntax you prefer. For now, we have that in one direction (the
> new system calls the old).

Okay I get it now. So the plan is not really to have two systems or to
deprecate one but just to have two APIs for using assumptions. The
name "old assumptions" lead me to assume that when the new system was
ready the previous would be deprecated and removed.

I do prefer the the new assumptions API so I would consider it an
improvement when it's ready. Of course there will be some cases where
you need to attach assumptions to objects because of
auto-simplification. There was a recent thread about using
commutative=False to prevent (a*b)/(a*c) from automatically
cancelling. I guess there's no new-style way to do that?

--
Oscar

[Aaron Meurer]

On Tue, Jan 19, 2016 at 7:57 AM, Oscar Benjamin <oscar.j....@gmail.com> wrote:

On 18 January 2016 at 20:47, Aaron Meurer <asme...@gmail.com> wrote:
>>> For now, I would recommend using the old assumptions. However, you can
>>> play with the new assumptions. The goal in making the new assumptions
>>> read the old was to make this easier to do.
>>
>> But it also makes it a confusing mish-mash of the two. What's the
>> eventual goal here?
>
> The eventual goal is to merge the two, so that one calls the other.
> Then it won't matter which one you use. It will just be a question of
> which syntax you prefer. For now, we have that in one direction (the
> new system calls the old).

Okay I get it now. So the plan is not really to have two systems or to
deprecate one but just to have two APIs for using assumptions. The
name "old assumptions" lead me to assume that when the new system was
ready the previous would be deprecated and removed.

That was the original plan. But we've come to realize that it's untenable.  

 

I do prefer the the new assumptions API so I would consider it an
improvement when it's ready. Of course there will be some cases where
you need to attach assumptions to objects because of
auto-simplification. There was a recent thread about using
commutative=False to prevent (a*b)/(a*c) from automatically
cancelling. I guess there's no new-style way to do that?

Cancellation isn't something that has been part of the assumptions system thus far. It happens automatically in the Mul constructor. I'm not sure if it really makes sense to try to solve this problem with the assumptions system. It's already a bit of a stretch to include commutative=False in the assumptions system. 

Aaron Meurer

 

--
Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQUB_eAmuu7OLQJfT%3DS4Zy2Q_7xh9fPkDDtO68zCpjYSg%40mail.gmail.com.