On Oct 30, 2006, at 7:44 PM, Martin Albrecht wrote:
> On Monday 30 October 2006 22:38, David Harvey wrote: >> I want to start applying our arithmetic architecture to _mul_. The >> fast >> pathway for __mul__ needs to be able to quickly identify the case of >> multiplying an element of a base ring of an algebra by an element of >> the algebra (or commutative algebra as the case may be). The >> sanest way >> to do this really fast is for base_ring to be a cdef attribute of >> Algebra and CommutativeAlgebra. >> >> Unfortunately this is going to run us into multiple inheritance >> problems with matrices (and possibly other things). Currently in >> William's development code, the MatrixSpace_generic class inherits >> from >> Generators. This has a bunch of cdef'd attributes. So it won't be >> possible to simultaneously inherit from Algebra too, if Algebra has a >> cdef'd base_ring. > > I've got an evil idea: What if Generators had a base_ring cdef'd? I > know that > this makes no sense for general Generators but it would only be one > single > pointer which isn't even visible to Python (i.e. not confusing the > higher > levels). A big fat warning in a comment where it is defined would > clarify > everything for library developers. It's a hack and probably to > reject but I > guess it should be on the table before being rejected. I had thought of that too. It's a hack. REJECT. >> On the other hand.... maybe this test doesn't need to be so fast >> after >> all. We can still test first for matching RingElement parents very >> quickly. If it's true that algebra elements are generally quite >> complicated objects, then probably a python attribute lookup is not >> such a big deal. Maybe I'm over-optimising. > > About the quite complicated objects: I guess the simplest/smallest > algebra > element I can think of is a dense matrix over GF(2), i.e. a > bitstring. That's > something SAGE should have in a very fast way. This is true. For such an object, here's what I know about the memory requirements for each element: * Python's ob_type field --- a single pointer * Python's reference count field --- a single word integer * _parent --- a single pointer * Some info describing the matrix data. I would expect in a typical implementation, this would be a pointer to a block of bits describing the entries. A really optimised implementation would probably store this inline with no separate pointer, but it would have to know the matrix size statically. So adding a base_ring pointer increases memory consumption by 25% at most. Actually it's less than that, due to overheads of memory management. David --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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/ -~----------~----~----~----~------~----~------~--~---
