Hi Fabian! thanks for your thoughts. Some comments below:
On Tue, Mar 23, 2010 at 10:10 AM, Fabian Pedregosa <fab...@fseoane.net> wrote: > Hi all. > > Since some of you are willing to improve the logic and assumption > system, I'll just say my opinion on the current state of these modules. > > The logic framework (sympy.logic) in my opinion is ok. Sure, it could be > improved with quantifiers (first-order logic) and other niceties, but > overall it fulfills its purposes, and after 6 months I believe it is > considered API stable. > > On the other hand, I am not at all happy with the assumption system that > I coded. It works, but there are some places that surely could be improved: > > - Performance. I have to restore to ugly hacks to have an acceptable > performance. See known_facts_compiled in assumptions.ask > > - Scalability. When the size of the known_facts database grows, the > performance grows exponentially. Plus, each time there is a query, a > Satisfiability solver is run over *all* variables. There are algorithms > that use previous knowledge to run faster. > > - API. The API is cumbersome and far too verbose (ask(x, Q.integer, > Assume(x, Q.rational) just to query if a rational is an integer). > Unfortunately, I do not know a better one. > > > The old assumption system > ------------------------- > Having the old assumption still around is a pain, but the core is > extremely fragile and removing the old assumption and plugging the new > one is not a trivial task. > > The HOWTO is rather simple: you remove the inheritance of Basic from > AssumeMeths, that is where all the old assumption framework is > encapsulated, and you start fixing tests. > > See this commit for an example on how this could be done.[1] > > Now you have two kinds of bugs. One type is derived from the fact that > the new assumption system supports less keys than the old one. This is > done because in the new system I removed all keys that where redundant > or could be derived from others. See also [1] for an example on how this > could be done. Note that you will have to re-generate > known_facts_compiled each time you add new keys. > > The other type of bugs are bugs that come from the fragility of the core > and are bugs that give strange (or simply different) results for things > that apparently have nothing to do with the core nor with the assumption > system. These bugs are really painful to solve and will likely not be > solved unless there is a real interest in the community and someone who > understands the core (Ondrej?) is willing to work on this. Of course I am willing to work on this. I don't understand the core more than anyone else, there are Add, Mul, Pow classes and that's it. If there is a bug, it has to be debugged, like any other python program. The way I debug bugs is just with print statements, or with pdb or winpdb, that's it. It takes time, that's for sure, but it can always be fixed. The idea is to get the new assumptions in, get most of the stuff working and stable, and then start fixing the subtle bugs one by one. The current assumptions in sympy are (very?) trivial, it just must be possible to make the new assumption engine fast for such a limited functionality. I will dig into this myself over the summer. I was accepted to Lawrence Livermore National Lab over the summer, where I'll be working on electronic structure, but over the weekends I should have some time and I'd like to do couple sympy sprints in the Bay Area. If you live around and are interested, let me know and I'll keep you posted on the sprints. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
