[Numpy-discussion] memory corruption bug

[Sven Schreiber]

I appreciate your warnings, thanks. However, they don't seem to apply
here, or why would my described workaround work at all in that case?
Also, afaict, the affected variable is not even passed to the class
where the problematic assignment happens.
-sven

Bill Baxter schrieb:
> You're sure it's not just pass-by-reference semantics biting you?
> If you make an array and pass it to another class or function, by
> default they just get a reference to the same array.
> so e.g.:
> 
> a = numpy.array ([1,2,3])
> some_class.set_array(a)
> a[1] = 10
> 
> Then both the local 'a' and the 'a' that some_class has are now [1,10,3].
> If you don't want that sharing then you need to make an explicit copy of
> a by calling a.copy ().
> 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).
> 
> 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, so if you
> pass a matrix A to a function in Matlab you can always treat it as a
> fresh local copy inside the function.  Not so with Python.  I found that
> locating and fixing those bugs was the most difficult thing about
> porting Matlab code to Numpy (that and the lack of some major toolkit or
> function you use in Matlab doesn't have an equivalent in Numpy... like
> eigs()).
> 
> --bb
> 
> 
> 
> On 8/26/06, *Sven Schreiber* <svetosch at gmx.net
> <mailto:svetosch at gmx.net>> wrote:
> 
>     Hi,
>     I experienced this strange bug which caused a totally unrelated variable
>     to be overwritten (no exception or error was raised, so it took me while
>     to rule out any errors of my own).
> 
>     The context where this is in is a method of a class ( Vecm.getSW()), and
>     the instance of Vecm is created within a different class (GG.__init__).
>     Now, the affected variable is in the namespace of GG (it's GG.urate),
>     and so I would think that anything local in Vecm.getSW () should not
>     affect GG.urate, right?
> 
>     Originally I did:
> 
>     glx[lag:, :] -= temp
> 
>     But that caused the described problem. Then I tried:
> 
>     glx[lag:, :] = glx[lag:, :] - temp
> 
>     But the same problem remains. Then I worked around the slice assignment
>     like this:
> 
>     temp4 = r_[zeros([lag, n_y]), temp]
>     glx = glx - temp4
> 
>     And everything is ok! However, when I alter the second line of this
>     workaround to:
> 
>     glx -= temp4
> 
>     The problem reappears! So I'm not even sure whether this is one or two
>     bugs...
> 
>     This is with yesterday's numpy svn on windows, but the same thing
>     happens with an earlier svn (~b2) as well. If you need further info,
>     please tell me how to provide it.
> 
>     Thanks,
>     Sven
>