[Numpy-discussion] In-place operations

[Francesc Altet]

El dt 12 de 09 del 2006 a les 13:17 -0400, en/na Pierre Thibault va
escriure:
> Hello again,
> 
> On 9/12/06, Francesc Altet <faltet at carabos.com> wrote:
> > Hello Pierre,
> > [...]
> >
> > Well, in some way, there is a temporary array creation that is
> > immediately bound to B, so in the end, the temporary is not so
> > temporary, but a new (bounded) object. Obviously, the object that was
> > referencing B is freed (unless there is another reference to it).
> 
> ok, I guess I was aware of all that. My worries are related to two cases:
> 1) When the mere creation of a new array is prohibitive.

As Archibald said in other message, creation of a big array is not an
issue (malloc is very fast) and indepent of the size:

>>> Timer("a=numpy.array(100,dtype=numpy.complex128)", "import
numpy").repeat(3,10000)
[0.19819307327270508, 0.14915895462036133, 0.14999985694885254]
>>> Timer("a=numpy.array(10000,dtype=numpy.complex128)", "import
numpy").repeat(3,10000)
[0.15171599388122559, 0.14998698234558105, 0.14901280403137207]

that is 15 us (in my old machine) irregardingly of the size.

[BTW, numpy.empty seems twice as slower in my machine. Why?
>>> Timer("a=numpy.empty(10000,dtype=numpy.complex128)", "import
numpy").repeat(3,10000)
[0.37033700942993164, 0.31780219078063965, 0.31607294082641602]
]

> 2) When what I really want to change is the _content_ of an array.
> Using assignment (=) disconnects B from the array it refers to, so
> that what used to be true (C=B) is not anymore.
> 
> I understant that B[:] = ...  solves the problem 2), though I don't
> know if this notation is recommended; but I would like to know if
> there is anyway to solve 1), in the way ufuncs can do.
> 
> I had fun using kde's "performance monitor" (ksysguard) to see the
> difference between
> 
> a = numpy.random.rand(2048,2048) + 1j * numpy.random.rand(2048,2048)
> a = numpy.exp(a)
> 
> and
> 
> a = numpy.random.rand(2048,2048) + 1j * numpy.random.rand(2048,2048)
> numpy.exp(a,out=a)
> 
> Not only is the latter faster, but I could see a large glitch in the
> memory usage for the former.

Yes, it seems that some ufuncs have an additional "out" parameter that I
was not aware of. Well, it that case, this parameter in the fft function
would solve your needs, although I don't know how complicated would be
this.

Cheers,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"