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 On Tue, Feb 12, 2013 at 1:40 PM, Matthew Rocklin <[email protected]> wrote: > 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. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
