On Wed, May 28, 2008 at 10:39 AM, Stéfan van der Walt <[EMAIL PROTECTED]>
wrote:
> 2008/5/28 Hoyt Koepke <[EMAIL PROTECTED]>:
> > In my experience tracking down these sorts of things, if the effect is
> > delayed and detected by glibc, it almost always means that a few bytes
> > beyond the end of the data part of an array have been overwritten.
> > This causes glibc's memory management stuff to crash later on when the
> > object is deallocated (or something like that). Of course, I should
> > say I was doing the overwritting in my own c code...
>
> If you look at the valgrind trace I sent earlier, you'll see that that
> is the case.
>
It's shape related.
In [7]: x = numpy.random.rand(5,2)
In [8]: y = ones((5,2))
In [9]: x.cumsum(None,out=y)
Out[9]:
array([[ 0.76943981, 1. ],
[ 1.12678411, 1. ],
[ 1.69498328, 1. ],
[ 2.50560628, 1. ],
[ 3.23050034, 1. ]])
In [10]: x.cumsum(None,out=x.reshape(10))
Out[10]:
array([ 0.76943981, 1.12678411, 1.69498328, 2.50560628, 3.23050034,
3.82341732, 4.78267467, 4.94663937, 5.39959179, 5.94577506])
In [11]: x.cumsum(None,out=x.reshape(10))
Out[11]:
array([ 0.76943981, 1.89622392, 3.5912072 , 6.09681347,
9.32731382, 13.15073114, 17.9334058 , 22.88004517,
28.27963696, 34.22541202])
In [12]: x.cumsum(None,out=x.reshape(10))
Out[12]:
array([ 0.76943981, 2.66566373, 6.25687093, 12.3536844 ,
21.68099822, 34.83172935, 52.76513516, 75.64518033,
103.92481729, 138.1502293 ])
Chuck
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
