On Jun 12, 2010, at 4:22 PM, Jason Grout wrote:
A few months ago, #8276 made the MatrixSpace identity_matrix and
zero_matrix methods return immutable matrices, following a
discussion on sage-devel. A consequence of this (unintended, I
hope!) was that the top-level identity_matrix and zero_matrix
methods now return immutable matrices. This now causes several
problems:
1. It breaks existing code
2. It makes the top-level matrix constructors inconsistent (every
other constructor in matrix/constructors.py returns a mutable matrix).
3. It breaks consistency with the 4 M's, which all return mutable
matrices from the top-level identity matrix constructor.
4. It requires someone that just wants to create a zero/identity
matrix and then modify it to either do copy(identity_matrix(...)) or
learn about MatrixSpace and do something like MatrixSpace(...)(1).
Both of these options require needless annoyances, especially for
someone that is just learning Sage or familiar with the 4 M's.
Note that the discussion for #8276 did not touch the top-level
constructors (it dealt with the matrix space methods), so this is a
different issue that brought up in #8276. The changes in #8276 to
the matrix space methods will still hold. Effectively, this
proposal is about changing the top-level identity_matrix function to
return MatrixSpace(...)(1) (a mutable copy) instead of
MatrixSpace(...).one().
So, please vote:
[ ] Yes, make top-level identity_matrix and zero_matrix functions
return mutable matrices again, i.e., this code will work, and will
not have the bugs #8276 pointed out:
sage: M=identity_matrix(3)
sage: M[0,0]=3
[ ] No, keep the changed behavior (this option entails requiring
users to do something like copy(identity_matrix(...)) or
MatrixSpace(...)(1) to construct a mutable identity matrix, like so:
sage: M=copy(identity_matrix(3))
sage: M[0,0]=3
The patch at
http://trac.sagemath.org/sage_trac/ticket/9212
implements the "yes" vote, and is ready for review (if the ticket is
reopened as a result of this vote.)
I vote yes as well, I think the primary motivation to do this was for
efficiency reasons, and we could do copy-on-write to handle that down
the road.
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
