GSoC- 2015 Assumptions

[Aaditya Nair]

Hi, 

I want to work on improving the assumptions as part of my GSoC- 2015 project.

Can somebody tell me the present status of the project and the prerequisite knowledge required for the project.

[Aaditya Nair]

I was reading up on the old blog post (http://matthewrocklin.com/blog/work/2013/02/05/Assuming/) and found out that few of those features have already been implemented.

Can someone tell me the current status of the project and what needs to be implemented.

[Aaron Meurer]

Assumptions are a pretty big undertaking. There are currently two
assumptions systems, the so-called old assumptions (Symbol('x',
real=True), x.is_real), and the so-called new assumptions (Q.real(x),
ask(Q.real(x))). We would like for there to be one.

If you want a place to start, look through the issues and pull
requests marked with the assumptions label (not all issues are labeled
properly, so you may want to just search for "assumptions"). A few of
the pull requests I've opened touch on the core issues (which is why
they haven't been merged yet; they require a lot of work to completely
"finish"), such as https://github.com/sympy/sympy/pull/7925,
https://github.com/sympy/sympy/pull/2508, and
https://github.com/sympy/sympy/pull/8134.

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 http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/e23a0b2d-0ebf-4531-a02c-c9b662061d62%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Aaditya Nair]

Suppose we were to choose the new assumptions over the old ones. Will it mean that the old assumptions are completely deprecated and removed from code-base. 

Because then, we will need to modify the whole code-base, not just the new assumptions.

[Aaditya Nair]

I have updated my Proposal to what I think needs to be done. At the moment I have assumed that we are making both assumption systems compatible to each other.

Please review and tell what more needs to be added.

[Aaditya Nair]

I have updated my proposal and added a timeline for the project.

Can you please review it ?

Aaditya M Nair

[Joachim Durchholz]

Am 15.03.2015 um 15:56 schrieb Aaditya Nair:
> I have updated my proposal

> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsympy%2Fsympy%2Fwiki%2FGSoC-2015-Application-Aaditya-M-Nair-%253A-Improve-the-assumptions-system.&sa=D&sntz=1&usg=AFQjCNGfaK8fPWMa5ZDncLWmQ4CxMPOJhg> and

> added a timeline for the project.
> Can you please review it ?

> 1. Remove incompatibilities between the old and new assumptions.
> [...] This project aims to correct that by adding a compatibility
> layer between the old and the new assumptions.

Is such a compatibility layer needed?
From previous discussion, I have been under the impression that it is
not, but then I haven't followed it very closely.

> 2. Since we ultimately want to shift to the new assumptions system.
> Make a few core components ( symbol, Add, Mul, etc ) use the new
> assumptions system and expand gradually.

Sounds like a good plan to me.
BTW I think this alone could well be enough work for a full GSoC. Making
changes of this kind involves not just review, but also writing
documentation and unit tests. These can easily double or triple the
total amount of work (but are *very* important).

> 3. instead of,
>>> facts = Q.positive(x) & Q.real(x) & Q.commutative(x)
>>> facts &= Q.positive(y) & Q.real(y) & Q.commutative(y)
>>> facts &= Q.positive(z) & Q.real(z) & Q.commutative(z)
> we could do something as
>>> factset = Q.positive & Q.real & Q.commutative
>>> facts=factset.apply(x, y, z)

That's a very cool idea.
If requires some changes to the API of Q, and probably some background
in higher-order functions.
Can you say a bit about how Q's API would look for that? I.e. a list of
functions that need to be made (or modified), and what each would do.

I'm not sure that the new assumptions system is ready for this addition
right now.

> 4. The present assumptions system creates a lot of bugs like #8873
> which are fixed through non-desirable hacks. The new system will
> provide a better and elegant solutions to them.

Move that from "Plan" to "Overview".
It's not something that you do, it's something that will happen.

> 5. (Adding examples to docstrings)

This could well be worth it.


Timeline Week-2
I suspect that making the old system interpret new assumptions isn't
going to work very well.
Logic inference algorithms tend to break down if you work with just a
subset of a body of known facts.

Overall, I suspect you're trying to do too much in too little time.
I may be wrong :-)

Just my thoughts. I bet others will have other things to say.

Regards,
Jo

[Aaditya Nair]

Thanks for reviewing the proposal. 

> 1. Remove incompatibilities between the old and new assumptions.
> [...] This project aims to correct that by adding a compatibility
> layer between the old and the new assumptions.  

Is such a compatibility layer needed?
 From previous discussion, I have been under the impression that it is
not, but then I haven't followed it very closely.

I thought the shift from old-assumptions to new assumptions was too big a change

for previous users to completely deprecate them in one go. So we keep both for some time and gradually remove the old ones.

 

> 2. Since we ultimately want to shift to the new assumptions system.
> Make a few core components ( symbol, Add, Mul, etc ) use the new
> assumptions system and expand gradually.

Sounds like a good plan to me.
BTW I think this alone could well be enough work for a full GSoC. Making
changes of this kind involves not just review, but also writing
documentation and unit tests. These can easily double or triple the
total amount of work (but are *very* important).

In retrospect, I now think that I bit off more than I could chew. They will take a much longer time than I expected.

Thanks for pointing it out.

 

 > 3. instead of,
 >>> facts  = Q.positive(x) & Q.real(x) & Q.commutative(x)
 >>> facts &= Q.positive(y) & Q.real(y) & Q.commutative(y)
 >>> facts &= Q.positive(z) & Q.real(z) & Q.commutative(z)
 > we could do something as
 >>> factset =  Q.positive & Q.real & Q.commutative
 >>> facts=factset.apply(x, y, z)

That's a very cool idea.
If requires some changes to the API of Q, and probably some background
in higher-order functions.
Can you say a bit about how Q's API would look for that? I.e. a list of
functions that need to be made (or modified), and what each would do.

I'm not sure that the new assumptions system is ready for this addition
right now.

If you think so, we could do it as a separate project. I think a few changes in Predicate class will do the trick.

 

Timeline Week-2
I suspect that making the old system interpret new assumptions isn't
going to work very well.
Logic inference algorithms tend to break down if you work with just a
subset of a body of known facts.

Overall, I suspect you're trying to do too much in too little time.
I may be wrong :-)  

Just my thoughts. I bet others will have other things to say.

Regards,
Jo

I have updated the proposal. (read: reduced some load) 

Thanks

Aaditya M Nair

[Aaditya Nair]

I just wanted to know, What will we be doing about Symbol assuming some assumptions by default (commutative) ?

Will they be explicitly defined or still assumed by default ?

[Aaron Meurer]

The commutative assumption is a tricky one. In the past, it's been
suggested that this doesn't really belong in the assumptions system.

As it stands now, we just have to make sure that things support some
assumptions being true by default.

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 http://groups.google.com/group/sympy.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/3945c0bf-9ff5-4e72-a2b7-cbac20383c7c%40googlegroups.com.

[Aaditya Nair]

I have updated my proposal to what I think should be done. It is most probably the final draft.

It will be very helpful to me if someone could review it. Especially the part about ManagedProperties.

Aaditya M Nair

[Joachim Durchholz]

Am 25.03.2015 um 20:11 schrieb Aaditya Nair:
> Especially the
> part about ManagedProperties.

Aside note: ManagedProperties might get split into two classes one of
these days (or weeks (or months, depending on how quickly I can get some
preliminaries out of the way)).
This isn't going to affect your changes much, except that they might go
into a class with a different name.

No need to worry about this now, it's just that we may have to
coordinate changes if we happen to get to ManagedProperties at the same
time.