On Oct 31, 2007, at 8:40 PM, Carl Witty wrote: > William just reported #1044, which I tracked down to the _rmul_c_impl > method in NumberFieldElement_quadratic. This code had: > cdef Rational c = <Rational>_c > but in this case, _c was actually an Integer. > > I'm not sure if _rmul_c_impl is actually allowed to assume that _c is > Rational. I think it may be, because the bad _rmul call is made by > LeftModuleAction.__init__, and I see a comment in that function, > # Objects are implemented with the assumption that > # _rmul_ is given an element of the basering > So it looks like LeftModuleAction is trying to make sure to only pass > a Rational to this function, but due to some bug is actually allowing > an Integer through. I haven't tried to understand this code in > LeftModuleAction, though, so I could be wrong.
I will look into this, but you are right that _rmul_c_impl requires an element of the basering. This is a property of the old coercion model, nothing new, and some rings assumed it already. > So that's the possible bug. Now for the concerns: > > 1) Is there a document describing the new coercion model? If so, > where? If not, there really needs to be... it's too complicated to > understand by reading the code (I've tried more than once). No, there is not, (at lest not all in one place) and what is currently there is a mix of the old and new models which makes it doubly bad. I am going to try and clean things up more while I change everything to use the new cpdef functions. > 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 if there was a recommended, documented > way to have an explicit set of efficient coercions/actions, we could > get pretty much all of Sage optimized within a few releases. That is optimistic, but perhaps possible. However, I would be wary of such a project before we have a benchmarking system to make sure we're actually fixing everything that we (massively) slow down. - 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/ -~----------~----~----~----~------~----~------~--~---
