Le jeudi 25 mars 2010 à 22:21 -0700, Ondrej Certik a écrit : > On Thu, Mar 25, 2010 at 6:46 PM, Brian Granger <ellisonbg....@gmail.com> > wrote: > > The logic in both refine.py and ask.py put all the logic for various > > classes in handlers. Currently, ask.py allows new handlers to be > > registered, but refine does not allow new handlers to be registered.
Beneath the quirky syntax, handlers are actually predicates implemented as generic functions. So you should be able to define new one, and have them registered automatically. > > * Has any though been given to allowing classes to optionally put > > refine and ask logic in their own methods optionally. I am thinking > > of this like printers. The default is to use the logic in the > > external printer classes, but if a class has the appropriate method > > (_latex_ etc), that is used. > > > > * Would it make sense to have .ask and/or .refine methods on classes > > that call refine and ask? Classes could have methods implementing specific behaviours for some handlers, or the handlers themselves could be altered at the place where the class is defined - in the current implementation, this means monkey-patching the handler class. I don't think having .ask would make sense: ask() is just plumbing for the assumption system, anything interesting should happen in the handlers. > > Yes, I would also define .simplify(), and maybe other methods in > Basic. Last time I sent the patch for this, it was opposed, that such > methods only make the Basic class (core) more complex. But I still > think that the most frequent methods (and simplify is one of them) > should be in the Basic. Also integrate. > > What do other think about this? That's quite exactly the opposite of what I've been trying to do. Having a big tangle of tightly coupled code is exactly what is preventing us from refactoring the core - and in particular, from replacing the assumption system. > > > > > * Shouldn't we have logic that allows new refine handlers to be > > defined for either already existing types or new types. This does > > look different than the ask handlers. There can be multiple ask > > handlers for a type, but only one refine handlers. Conceptually, refine is just simplify with a specifiable set of assumptions instead of a global one, so they should be merged somehow. On the API side, 'refine(abs(x), Assume(x, Q.positive))' should become something like 'simplify(abs(x), assuming=positive(x))' or 'with positive(x): simplify(abs(x))'. Ronan -- 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.
