> 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.
Could you clarify this? Does this apply only for ask handlers? (assumptions.handlers) I don't see any logic for adding new refine handlers (even by hand). >> > * 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 guess that makes sense. I was thiniking that foo.ask would be a way of asking foo about its assumptions. But, I think you are right on this. >> 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. I think this is a bigger issue and I if I am feeling up to it I might summarize the issue in the new thread. >> > * 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))'. Yes, it does make sense that refine and simplify are pretty similar in functionality. I do think they should be combined. Cheers, Brian > 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. > > -- 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.
