Hi,<br><br><div><span class="gmail_quote">On 8/26/06, <b class="gmail_sendername">Bill Baxter</b> <<a href="mailto:wbaxter@gmail.com">wbaxter@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>You're sure it's not just pass-by-reference semantics biting you?<br>If you make an array and pass it to another class or function, by default they just get a reference to the same array.<br>so e.g.:<br><br>a = numpy.array

([1,2,3])<br>some_class.set_array(a)<br>a[1] = 10<br><br>Then both the local 'a' and the 'a' that some_class has are now [1,10,3].<br>If you don't want that sharing then you need to make an explicit copy of a by calling 
a.copy
().<br>Watch out for lists or dicts of arrays too.   The python idom for copying a list:  new_list = list_orig[:], won't copy the contents of elements that are array.  If you want to be sure to make complete copies of complex data structures, there's the deepcopy method of the copy module.  new_list = 
copy.deepcopy(list_orig).<br><br>I found a bunch of these sorts of bugs in some code I ported over from Matlab last week.  Matlab uses copy semantics for everything, </div></blockquote><div><br>Matlab does copy on write, so it maintains a reference until an element is modified, at which point it makes a copy. I believe it does this for efficiency and memory conservation, probably the latter because it doesn't seem to have garbage collection. I could be wrong about that, though.
<br><br>Chuck<br></div><br></div><br>