[SciPy-user] How to free memory allocated to array in weave.inline?

Fernando Perez fperez.net at gmail.com
Sun Aug 26 15:50:20 EDT 2007


On 8/26/07, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> What really bothers me is that it does not work if I use empty instead of
> ones. It must be due to a type problem, probably the blitz converters not
> guessing properly the type of the input array, but I'd really appreciate
> some better explaination of that, and some info on the right way to use
> empty with inline.

Well, since I opened my mouth, I figured I better finish.

With both current SVN and Jarrod's release, I can't see any problems.
It works fine for me with both empty() and ones().  Note that blitz
arrays are 0-offset, that may have confused you.  Here's my code:

n [4]: !cat sciweave.py
"""Simple weave test.
"""
from scipy import weave
from numpy import empty,ones

def my_array(shape,alloc):
    nx, ny = shape


    ar = alloc(shape)
    code = """
   for (int i=0; i<nx; ++i) {
       for (int j=0; j<ny; ++j) {
           ar(i, j) = (double) i*j ;
       }
   }
   """
    print 'ar before weave call:\n',ar
    weave.inline( code, ['ar', 'nx', 'ny'],
                   type_converters=weave.converters.blitz, )
    return ar

a = my_array((4, 4),empty)
print '\n a is:\n',a

a = my_array((4, 4),ones)
print '\n a is:\n',a

#### EOF

and the result:

In [5]: run sciweave.py
ar before weave call:
[[  7.07989597e+000   1.68382620e+212   5.83403689e-302   1.68464810e+212]
 [  7.54004556e-309  -2.05446830e-289   8.89269073e-309   1.45261128e-296]
 [  1.04007959e+034   8.89422392e-309   1.45261245e-296   1.04007959e+034]
 [  1.02794628e-308   1.04033438e+034   1.76125890e-312   1.08646184e-311]]

 a is:
[[ 0.  0.  0.  0.]
 [ 0.  1.  2.  3.]
 [ 0.  2.  4.  6.]
 [ 0.  3.  6.  9.]]
ar before weave call:
[[ 1.  1.  1.  1.]
 [ 1.  1.  1.  1.]
 [ 1.  1.  1.  1.]
 [ 1.  1.  1.  1.]]

 a is:
[[ 0.  0.  0.  0.]
 [ 0.  1.  2.  3.]
 [ 0.  2.  4.  6.]
 [ 0.  3.  6.  9.]]


The behavior looks perfectly normal to  me in both cases, and I don't
get any segfaults here.  I looked at the  auto-generated C++ code and
I don't see anything wrong there.

So I guess *don't* report it as a bug :)

Cheers,

f



More information about the SciPy-User mailing list