I just realized that I was using a seriously outdated version of sage ( 2.6.something). Using 2.7.2.1, scalar division on matrices does work. In case anybody was wondering.
However, I am still confused on your response regarding Matrix being derived from AlgebraElement. Are you saying that Matrix is supposed to be derived from AlgebraElement? Why? Matrices don't form an algebra. It seems that Matrices being derived from either ModuleElement or AdditiveGroupElement makes more sense. Come to think of it, how come AdditiveGroupElement is derived from ModuleElement and not the other way around? Cheers, Soroosh On 7/30/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > > On Jul 30, 2007, at 12:45 PM, Soroosh Yazdani wrote: > > > Hi, > > > > I am trying to implement scalar division in sage, and I'm starting > > to get a bit confused about the class hierarchy. I believe that a > > while ago there was some discussion about the class hierarchy, but > > I have no idea what the results were, and I figured I will just ask > > my questions here. > > The arithmetic model just recently changed, so it's good you're > asking these questions. > > > First, the header of element.pyx says that RingElement is derived > > directly from Element, however in the code, RingElement is derived > > from ModuleElement. I assume that having RingElement derived from > > AdditiveGroupElement also makes sense, and I don't see any problem > > changing the code to reflect that. > > Trust the code, not the documentation :-). Eventually, I think it > would be nice if that documentation were auto-generated. This is > because there is a lot of "basering" code (e.g. the base-ring of Z[x] > is Z) that is implemented at the module element that rings take > advantage of. Rings are always modules over themselves so that is > consistent. Perhaps AdditiveGroupElement would be OK too. > > > However, maybe there is a good reason why it should be derived from > > Element directly. > > > > Second, looking at the code it seems that Matrix is derived from > > AlgebraElement, which doesn't make sense to me. > > That is correct. > > > Should the class Matrix be called MatrixElement for consistency? > > Also, should AlgebraElement be something like AlgebroidElement? > > Probably that's a terrible idea. Is it worthwhile to create a new > > class SquareMatrixElement? > > There is no multiple inheritance for Python extension types (pyrex/ > sagex/cython) so a SquareMatrixElement class wouldn't make sense (one > would have to subclass each specialized matrix class, e.g. integers, > rationals, Z/nZ, etc.) > > > Also, I think it makes sense to have the default for __div__(left, > > right) to be __mul__(left, ~right). This seems to implement many > > division operations that are not implemented already (such as > > matrix division and scalar division). However, for that to work, we > > need __invert__ to be defined. As it stands, __invert__ (in > > RingElement) calls __div__. Does it make sense to rewrite > > __invert__ to do all the hard work, and leave __div__ to be fairly > > generic? > > __div__ often returns elements of a new ring (e.g. the fraction > field). I think __invert__ should be generic (and call __div__) > rather than the other way around, if just for efficiency reasons. > Usually __invert__ has to create an element (1) and then create a > fraction which would then be multiplied in __div__. Note that the > _div_(left, right) that is actually implemented in the ring assumes > left and right are of the correct type. > > As for scalar multiplication, this is (as of Sage 2.7.1) handled via > actions. For example, consider A in Q[x] and c in Q. When one types > A*c, it tries to find a (right) action of c on A corresponding to the > operator *, and in this case returns that right multiplication is > defined. If you do A / c, it does the same (tries to find right > action of c on A associated to the operator /) and, that failing, > looks for an action A * (1/c) > > - 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/ -~----------~----~----~----~------~----~------~--~---
