On Jun 11, 2010, at 1:42 AM, Florent Hivert wrote:
Hi Robert,
Rob and I were just talking yesterday how it's so inconvenient that
identity_matrix() now returns an immutable matrix, so constructing
something from it involves making a copy, which is not the most
obvious
thing to a new person, or the most elegant thing to someone that
has been
using matrices for a while now. It would be fantastic if immutable
matrices had copy-on-write semantics, not necessarily for
performance, but
just for usability after some of the recent design decisions
(which I
guess were made for performance reasons).
Copy on write *should* be rather easy to implement for matrices at
least.
This is both true and false:
Making the data-structure for having copy-on-write object is fairly
easy. This
is just aving an extra level of indirection and we have something
good for
that in sage-combinat queue (see [1]). Note that if this patch were
be really
used, it certainly should be Cythonized.
The main problem for COW is a problem of syntax. If obj is a python
object
then
obj1 = obj
makes only a new reference on the *same* object. Unfortunately in
Python, there
is now way to change that like overloading operator::= in C++.
Personally, I think not being able to execute arbitrary code on
assignment is a feature not a bug :)
if you want to
make a new *semantic copy* you have to use a different syntax. The
way we
tried that in our experiment is
with obj.mutable(): # obj is now a new semantic copy of itself
# copy is done here if needed.
obj[1] = 1 # in place modifications
The result of the experiment is that, given you have to use this new
syntax,
most of the time if you use it, you really need a *new* copy. The
overhead of
COW is simply not worth it. Therefore we decided that the prototype
design
pattern was better suitable to our need than COW. Of course, if
there was a
was to overload "=" things were completely different.
My proposal is not to make everything copy on write by default, but
rather to make the copy() method lazy. This would be a smaller step,
but still useful. In particular, this wouldn't change any current Sage
semantics, but would only be an optimization feature. The prototypical
use case is when something returns a matrix that's worth caching, but
doesn't know if the user just wants to read it, or might want to
modify it. As for the overhead, one could put the copying code in
clear_cache(), and there would be no need for an extra layer of
indirection.
- 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
