New new assumptions issue

[Matthew Rocklin]

We should attract a GSoC student to solve the new assumptions problem.  Because this problem is both complex and important to many of us I think that we should define it explicitly.

I have created the following issue

Migrate from old assumptions to new assumptions

Note that there are several such issues floating around in the issue tracker.  I have made the n+1th in hopes that it will be the last. (foolish me)

No discussion should happen on this issue itself.  Rather it is there to collect other, hopefully more atomic issues.  So far I have collected/created the following

New assumptions should be fast

Contradictory assumptions should raise an error

is_attribute syntax in core

Backwards compatibility with old assumptions

Relational assumptions

Several modules depend on the old assumptions structure

Some of these like "new assumptions should be fast" and "several modules depend on old assumptions structure" should also be broken up into several smaller issues like "caching results for new assumptions" or "physics should use new assumptions" etc....

I encourage anyone with knowledge of new assumptions to create more issues and add discussion/wisdom where necessary.  I think that a description of the problem broken down in this way will make this problem approachable to an industrious student.

Previous discussions on this topic are long and meandering, requiring great patience.  Problems are easier when broken down.  I hope that this structure breaks the new assumptions conversation and problem down into achievable pieces.

[Aaron Meurer]

Another aspect of assumptions that hasn't really been touched upon yet
is the refine() function. I guess it should probably wait until
everything else is done, but any GSoC project dealing with assumptions
will need to talk about it.

Thanks for taking the initiative here. I think the most important
thing we can do, aside from breaking down the problem, is to decide
once and for all on the API that we want, as well as make final
decisions on other issues. Otherwise, any student working on this
will be a slave to the community and his/her project could be
effectively halted while we make up our minds about something. And it
won't be very good if a student implements a bunch of things and then
we decide that we actually want it completely different.

Also, if we really want to attract a student to this issue, we should
improve the idea on the ideas page.

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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>