Vinzent: Thank you for picking through it all. I've fixed everything you mentioned, and just included an update with new comments / docstrings (a common thread of feedback you had).
Branch: http://github.com/haz/sympy/tree/soc-final-fixed <http://github.com/haz/sympy/tree/soc-final-fixed>Docstring Commit: http://github.com/haz/sympy/commit/9af23ff2bdf720999789d988d94cd36c9dc53b0f <http://github.com/haz/sympy/commit/9af23ff2bdf720999789d988d94cd36c9dc53b0f> Let me know if there's anything else that should be fixed up. Thanks again. Cheers Christian On Fri, Aug 13, 2010 at 1:33 PM, Vinzent Steinberg < vinzent.steinb...@googlemail.com> wrote: > I posted some comments on github, I'll yet have to run the tests however. > > Vinzent > > 2010/8/11 Christian Muise <christian.mu...@gmail.com>: > > Ok, so I went through the growing pains of figuring all this git stuff > out, > > at we should be good to go with this branch: > > - http://github.com/haz/sympy/tree/soc-final-fixed > > The commits are linear, all tests should be running clean (regardless > of > > commit now, not just the head), and the trivial commits for fixes were > > squashed into the appropriate commits where the problem cropped up in the > > first place. > > Merging the known fact forms will be post-SoC, and done with this > issue: > > - http://code.google.com/p/sympy/issues/detail?id=2016 > > ...and getting the compiled forms to be changed online will be > addressed > > with this issue: > > - http://code.google.com/p/sympy/issues/detail?id=2017 > > Please let me know what else I can / should fix up in the current > branch > > for inclusion (that's my main goal for this final week). > > On the topic of re-computing things online -- I should be able to > detect > > and throw an error when an inconsistency is formed (since we have > > precompiled things already), and updating the known_facts_* will just be > a > > form of belief revision...definitely doable. But it should be noted that > > these known facts are separate from default assumptions or assumption > > contexts. Both of which already exist. The default assumptions can go > into > > global_assumptions (importable from sympy), and if you would rather use > your > > own context, that's doable as well -- see this test case that > demonstrates > > it: > > - > http://github.com/haz/sympy/blob/soc-final-fixed/sympy/assumptions/tests/test_query.py#L947 > > The known facts are reserved for mathematical truths: > > - > http://github.com/haz/sympy/blob/soc-final-fixed/sympy/assumptions/ask.py#L233 > > ...and these aren't likely to change too much unless someone is > introducing > > new predicates. > > Thanks again for all the feedback everyone. > > Cheers > > Christian > > > > On Wed, Aug 11, 2010 at 1:14 PM, Aaron S. Meurer <asmeu...@gmail.com> > wrote: > >> > >> On Aug 11, 2010, at 3:00 AM, Vinzent Steinberg wrote: > >> > >> > 2010/8/10 Aaron S. Meurer <asmeu...@gmail.com>: > >> >> Would it be possible to persistently cache the result, so that it's > >> >> computed once on an import, but then saved somewhere so that future > imports > >> >> don't need to do it. Maybe something that could be done by setup.py. > >> > > >> > I think this would be the cleanest solution, however we would need to > >> > introduce a writable directory for sympy. It's no problem if the first > >> > import of sympy takes 20 s (or every import where the facts were > >> > changed in the code), especially if this is done by setup.py, so the > >> > user won't even notice. > >> > > >> > The writable directory could also have the config file (another nice > >> > thing to introduce) and compiled code from codegen. > >> > > >> > Vinzent > >> > >> And files from preview(). And I suppose that if you configure it to not > >> be available, which might be necessary in certain environments, then it > will > >> have to just do it at import time every time. > >> > >> Aaron Meurer > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "sympy-patches" group. > >> To post to this group, send email to sympy-patc...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> sympy-patches+unsubscr...@googlegroups.com<sympy-patches%2bunsubscr...@googlegroups.com> > . > >> For more options, visit this group at > >> http://groups.google.com/group/sympy-patches?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sympy-patches" group. > > To post to this group, send email to sympy-patc...@googlegroups.com. > > To unsubscribe from this group, send email to > > sympy-patches+unsubscr...@googlegroups.com<sympy-patches%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/sympy-patches?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "sympy-patches" group. > To post to this group, send email to sympy-patc...@googlegroups.com. > To unsubscribe from this group, send email to > sympy-patches+unsubscr...@googlegroups.com<sympy-patches%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/sympy-patches?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patc...@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
