Robert Bradshaw wrote:
> On Sep 27, 2007, at 4:43 AM, Jason Grout wrote:
> 


>> A=A.union(B)
>>
>> to modify A?
> 
> Yes. Or even
> 
> A.inplace_union(B)
> 
> (or some better name than that) which returns nothing. Otherwise, for  
> example, every function that received a graph as an argument would  
> have to make a copy to avoid side effects (or the calling function  
> would always have to make a copy before passing in just in case).  
> Explicitly making a copy everywhere seems cumbersome.

Thanks for the direct and good advice.  I guess I had convinced myself 
that an object method would naturally do something to the object, so it 
was pretty natural to always modify in-place.




> 
>> It's slightly worse performance-wise, it seems, because we
>> are always making copies and throwing old copies away.  Especially  
>> if we
>> have the above (A.union(B).union(C).union(D).union(E))---then we  
>> make 4
>> new copies of things and throw away all but 1 of them.
> 
> True, this is the price to pay. It might be worth having a function  
> that does things inplace if one needs the speed, but I like to avoid  
> side effects in general. Though I think the syntax above is the  
> clearest, A.union([B,C,D]) could be done more efficiently.

Is this the sort of situation your ref-counting stuff would enhance? 
For example, in the above situation, if a new object were returned by 
union, then A.union(B) would not be referenced anywhere else in the 
system, so A.union(B).union(C) would actually not create a new object, 
but do the union in-place in A.union(B)?  So the system would understand 
that the following code:

def union(self, othergraph):
     g=self.copy()
     # Modify g to be the union of g and othergraph
     ...
     return g

should make a copy of self in the A.union(B) case, but not make a copy 
when invoked in the .union(C) case above.

Am I understanding the idea behind your ref-counting thread mentioned 
elsewhere?

Thanks,

Jason



--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---

Reply via email to