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.)
Thanks,
Jason
> 3. It breaks consistency with the 4 M's, which all return mutable
> matrices from the top-level identity matrix constructor.
Correction: Maple identity matrices are immutable. However, Magma,
Mathematica, and Matlab matrices identity matrix top-level commands all
return mutable matrices.
Thanks,
Jason
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
John
Then I vote yes to your proposal.
William
> Thanks,
>
> Jason
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org