I suppose my objection to the PRESS program is not the "organization" per se, It could be that knowledge of mathematics can be encoded procedurally or functionally or as pattern matches or as rules. Frankly, I have my own bias, having worked with several of these.
What I object to is the mind set of the programmers that there is, essentially, no point in encoding mathematics at all, just some collection of mimicking what students might do in their flailing around trying to answer certain kinds of examination questions. I suppose one could argue that there is no "there" there, and all of mathematics is just pushing symbols around on paper, and you just need more and more rules to achieve a higher and higher grade on exam questions. This is sometimes portrayed as a view that you start knowing nothing and just "debug". And maybe that is how infants learn, at least initially. If those rules become "high level" in some way perhaps there is a route to something that could pass for knowledge, and might even answer unanticipated questions. But the particular PRESS rules are weak, and the fact that the answers cannot be checked is a hint that it doesn't really contain the concepts of mathematics in a systematically complete way. RJF On Tuesday, June 3, 2014 8:50:10 AM UTC-7, F. B. wrote: > > More than the logic contained in PRESS, I would get inspiration for the > programming style. > > The current sympy solve has a lot of manual dispatching through "IF" and > recursion. The code is hard to read, and you also need a debugger to > understand what happens to expressions. I would suggest to either use a > logical style (like PROLOG rules, there is the logpy project which is > trying to implement that paradigm in Python), or pattern dispatch (as in > Wolfram Mathematica). > > An example of a possible implementation of a solver using pattern dispatch: > > @patterndispatch(cos(A), x, assumptions=Q.has(A, x) & Q.instanceof(x, > Symbol)) > def solve(f, x): > return # solutions to cos(A) == 0, call solve(A - zeros of cos(), x) > > @patterndispatch(cos(A)+B, x, assumptions=Q.has(A, x) & not Q.has(B, x) & > Q.instanceof(x, Symbol) > def solve(f, x): > # code > > This would make the code a lot more readable, solutions would be mapped to > very specific cases, and there would no need to manually create lots of > IFs, because the @patterndispatch decorator would store and use the > dispatching information properly (e.g. in a directed acyclic graph). This > was the style pursued by Wolfram Mathematica and it proved very successful. > > Alternatively, the logic programming style of PRESS could be implemented > into SymPy by creating a dependence to LogPy. > > I really believe that the code should become more readable. I would favour > the introduction of a pattern dispatching decorator with joint assumptions. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to sympy@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/dc2d5206-a1c5-4183-ad43-e893b5d95f86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
