On Wed, 31 Oct 2007 23:41:46 -0700, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > On Oct 31, 2007, at 8:40 PM, Carl Witty wrote: >> 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.
Yep. And in many cases ignoring that requirement will lead to a segfault. It's the same as how _mul_c_impl, _add_c_impl, etc. all work. It was the whole idea of the original "arithmetic architecture" stuff David Harvey came up with at Sage Days 2, i.e., make it possible to code a fast pathway under certain assumptions. >> 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. Those will likely help a lot with readability. >> 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 personally agree, that no matter what you'll have to define those functions, so why not make them the only ones you have to define. It's very simple and straightforward. >> 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. +1 -- William --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
