Trac #8276: The one of MatrixSpace can be changed !
Florent Hivert
I have a slightly stupid question ! First of all consider the following
behavior (sage 4.3.2):
sage: A = MatrixSpace(ZZ, 3)
sage: A.one()
[1 0 0]
[0 1 0]
[0 0 1]
sage: A.one()[1,2] = 1
sage: A.one()
[1 0 0]
[0 1 1]
[0 0 1]
This is definitely bad. It happens because one is generically computed by
coercion from 1 and then cached without making it immutable. I see at least
three solutions:
1. - Don't cache at all
2. - Return a cached immutable
3. - Return a mutable copy of a cached
To have an idea of the usage I went trough the code:
- MatrixSpace.identity_matrix implement 1.
- MatrixSpace.zero_matrix implement 3.
Of course, my opinion is to make those three methods implements 2. :-)
Any arguments in favor one or one other ?
Cheers,
Florent
William Stein
<florent...@univ-rouen.fr> wrote:
> Hi there,
>
> I have a slightly stupid question ! First of all consider the following
> behavior (sage 4.3.2):
>
> sage: A = MatrixSpace(ZZ, 3)
> sage: A.one()
> [1 0 0]
> [0 1 0]
> [0 0 1]
> sage: A.one()[1,2] = 1
> sage: A.one()
> [1 0 0]
> [0 1 1]
> [0 0 1]
>
> This is definitely bad. It happens because one is generically computed by
> coercion from 1 and then cached without making it immutable. I see at least
> three solutions:
>
> 1. - Don't cache at all
> 2. - Return a cached immutable
I strongly vote for 2.
> 3. - Return a mutable copy of a cached
>
> To have an idea of the usage I went trough the code:
>
> - MatrixSpace.identity_matrix implement 1.
> - MatrixSpace.zero_matrix implement 3.
>
> Of course, my opinion is to make those three methods implements 2. :-)
+1
> Any arguments in favor one or one other ?
I like 2. If you need a copy to mutate, then you can always do A.one().copy().
William
>
> Cheers,
>
> Florent
>
> --
> 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
Associate Professor of Mathematics
University of Washington
http://wstein.org
Jason Grout
+1 for doing option (2).
Jason
Nick Alexander
>>
>> - MatrixSpace.identity_matrix implement 1.
>> - MatrixSpace.zero_matrix implement 3.
>>
>> Of course, my opinion is to make those three methods implements
>> 2. :-)
>
> +1 for doing option (2).
I very often want to start with the zero_matrix or the identity_matrix
and "fill in" the rest of the matrix. But I also want the access
routines to be fast! So I vote for copy-on-write semantics, if
possible.
Nick
William Stein
Nick's suggestion is definitely a (4) -- it's nothing like any of
(1)-(3) in this discussion. It could be done, but would be a *lot* of
work (certainly way more than 1-3), and would likely slow down all
writes somewhat. But it's possible.
William
Tom Boothby
> "fill in" the rest of the matrix. But I also want the access routines to be
> fast! So I vote for copy-on-write semantics, if possible.
+1
Robert Bradshaw
>>> To have an idea of the usage I went trough the code:
>>>
>>> - MatrixSpace.identity_matrix implement 1.
>>> - MatrixSpace.zero_matrix implement 3.
>>>
>>> Of course, my opinion is to make those three methods implements
>>> 2. :-)
>>
>> +1 for doing option (2).
I also think option (2) is far superior to (1) and (3).
> I very often want to start with the zero_matrix or the
> identity_matrix and "fill in" the rest of the matrix. But I also
> want the access routines to be fast! So I vote for copy-on-write
> semantics, if possible.
If/until copy-on-write is implemented, manually copying before write
will have the same performance attributes.
- Robert
Florent Hivert
> On Mon, Feb 15, 2010 at 9:07 PM, Nick Alexander <ncale...@gmail.com> wrote:
> >>> To have an idea of the usage I went trough the code:
> >>>
> >>> �- MatrixSpace.identity_matrix implement 1.
> >>> �- MatrixSpace.zero_matrix implement 3.
> >>>
> >>> Of course, my opinion is to make those three methods implements 2. :-)
> >>
> >> +1 for doing option (2).
> >
> >
> > I very often want to start with the zero_matrix or the identity_matrix and
> > "fill in" the rest of the matrix. �But I also want the access routines to be
> > fast! �So I vote for copy-on-write semantics, if possible.
Yes ! I noticed that when preparing my patch. If we decide to let zero_matrix
return an immutable matrix, then in several places of sage, an explicit copy
must be added (I can do that if needed). So it will be somehow a backward
incompatible change forcing the user to change their code. Of course this is
because they used an undocumented feature namely that zero_matrix is
immutable.
Nevertheless, I'm still in favor of option (2). Indeed this is the safest
option and in case of bad usage (trying to modify an immutable matrix) the
error message is very explicit and explicative:
sage: MS = MatrixSpace(ZZ,4)
sage: a = MS.one()
sage: a[1,2] = 3
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
...
ValueError: matrix is immutable; please change a copy instead (i.e., use copy(M) to change a copy of M).
> Nick's suggestion is definitely a (4) -- it's nothing like any of
> (1)-(3) in this discussion. It could be done, but would be a *lot* of
> work (certainly way more than 1-3), and would likely slow down all
> writes somewhat. But it's possible.
With Adrien Boussicault, we wrote some generic code to have copy on write for
combinatorial object (see [1]). Aside performance and usability issues, the
main problem is that in Python, the assignment operator has a binding
semantics: it binds the given object to a new variable, no new object can be
created. It cannot be overloaded as in C++ for example. So that you have to
somehow explicitely write that you want a new semantic copy, the actual copy
being delayed.
Any comment or vote ?
Florent
[1] http://combinat.sagemath.org/hgwebdir.cgi/code/file/6a2c5038c298/sage/combinat/copyonwrite.py#l1