Hi Robert, >>> 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 :)
I more or less agrees with that... >> 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. Well ! I not sure to understand exactly... So you want to return a (semantic) copy of what is cached, right ? So any function returning a matrix (say inverse) will have to explicitely call "return copy(result)". So inverse is only computed once. But still, do you return a mutable or immutable matrix ? Or maybe with this COW you don't want to distinguish anymore ? > 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. So basically you still want to write A = copy(B) # create a semantic copy but no actual copy is done A[1,2] = 4 # the copy is triggered... An since the actual entries of the matrix are stored in an attributes called _entries, two different matrix objects can have share the same entries so that the matrix object is doing the indirection for you. So this sound good and not very hard to do... Cheers, Florent -- 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
