On Nov 1, 2007, at 1:26 PM, Carl Witty wrote: > On Oct 31, 11:41 pm, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: >> On Oct 31, 2007, at 8:40 PM, Carl Witty wrote: >>> 2) The automatic detection of possible actions scares me. It seems >>> fragile and overly magical. Would it be possible to disable this >>> (which would presumably slow things back down), then document a way >>> for classes to have fast coercions/actions (preferably in the >>> Programmer's Guide)? >> >> Right now, to define an action, one simply has to define any of >> _rmul_, _lmul_, _r_action_, and _l_action_. The first two assume the >> other element belongs to the basering. Is there a simpler way for the >> _user_ to define an action? > > I think what I mean is that most of get_action_c_impl should be > removed, and that parents that want fast actions should be required to > set ._action_list (presumably by passing actions= to > Parent.__init__).
I originally envisioned passing everything up through the __init__ functions, but this is really messy as not all parents call their super's __init__ method, and there is so much multiple-inheritance among then that __init__ may get called multiple times too. Also, to construct (say) an action, one needs pass in self, which (before makes the call to Parent.__init__) may be incomplete. > In particular, comments like: > # TODO: if _xmul_/_x_action_ code does stuff like > # if self == 0: > # return self > # then _an_element_c() == 0 could be very bad. > worry me. Yeah. Perhaps _an_element should be renamed to _nontrivial_element. > It seems like you're trying to guess things about how types are > implemented by probing them from outside, and that this is likely to > break for slightly-odd types. I want to make it as easy as possible for a user to provide right/ left multiplication, and the most natural thing to do seems to detect whether or not such functions are implemented. Clear specification on what _xmul_ should do and how it will be used should help greatly here. > Perhaps I wouldn't be worried if there were a clear, not-too- > complicated checklist for how to make sure a type works with the > coercion model. Things like "if _r_action accepts any value with > parent A, then it must accept all values with parent A" -- if that is > indeed a requirement of the coercion code. Point well taken, and I should be the one writing this all up (though if anyone else wants to volunteer I'd be very glad). - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
