> I think the reason for subclassing in this case is code-reuse. But that's in itself a dangerous thing to do if we change the class' internal > behavior by this much. People changing the code for Matrix_dense shouldn't need to deal with issues in a non-conforming subclass -- > but they will have to when their changes suddenly cause doctests to fail.
The probelm with that is that conforming properly to the interface (by creating a new Mutability object every time we instantiate a 2x2 integer matrix) results in slowing down 2x2 matrix multiplication by a factor of about 5. Since the special 2x2 matrix class is about 10 times faster for multiplication than the generic Matrix_integer_dense, this would almost totally destroy the point of having a special-case class for the 2x2 case in the first place. I have a suggestion for a workaround: create a single Mutability object which is constant over each Sage session and is set to immutable, and assign this to the _mutability slot in _new_c. This means that we still preserve most of the speed advantage of the 2x2 integer matrix class, but it still conforms to the specification modulo the fact that it's not possible to create a mutable Matrix_integer_2x2. The downside is that we'd potentially end up with a situation where some Matrix_integer_2x2 objects will have "their own" Mutability objects, and some will have a pointer to a single global Mutability object, which is a bit mind-bending; but that doesn't matter since we will never change the global 2x2 matrix Mutability object anyway. David -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
