Re: [sage-devel] Re: Trac #8276: The one of MatrixSpace can be changed !
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. +1 -- 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
Re: [sage-devel] Re: Trac #8276: The one of MatrixSpace can be changed !
On Feb 15, 2010, at 9:07 PM, Nick Alexander 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 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 -- 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
Re: [sage-devel] Re: Trac #8276: The one of MatrixSpace can be changed !
On Mon, Feb 15, 2010 at 09:21:00PM -0800, William Stein wrote: On Mon, Feb 15, 2010 at 9:07 PM, Nick Alexander ncalexan...@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 --- ValueErrorTraceback (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 -- 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
[sage-devel] Re: Trac #8276: The one of MatrixSpace can be changed !
On 02/15/2010 03:19 PM, Florent Hivert 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 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 for doing option (2). Jason -- 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
Re: [sage-devel] Re: Trac #8276: The one of MatrixSpace can be changed !
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. Nick -- 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
Re: [sage-devel] Re: Trac #8276: The one of MatrixSpace can be changed !
On Mon, Feb 15, 2010 at 9:07 PM, Nick Alexander ncalexan...@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. Nick 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 -- 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
