numpy-discussion — Discussion list for all users of Numerical Python

[Numpy-discussion] Re: Garbage collection fails after numarray exception

[Leo B. <le...@ls...>]

Rob Hooft <ro...@ho...> writes:

> > On Tue, 2004-02-10 at 15:09, Leo Breebaart wrote:
> > 
> >>   >>> import numarray
> >>   >>> a = numarray.zeros(100000000)
> >>   >>> del a
> >>   >>> a = numarray.zeros(100000000)
> >>   >>> a + ''
> >>   Traceback (most recent call last):
> >>     File "<stdin>", line 1, in ?
> >>     File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 664, in __add__
> >>       return ufunc.add(self, operand)
> >>     File "/usr/lib/python2.3/site-packages/numarray/ufunc.py", line 870, in _cache_miss2
> >>       (in1, in2), insig, scalar = _inputcheck(n1, n2)
> >>     File "/usr/lib/python2.3/site-packages/numarray/ufunc.py", line 391, in _inputcheck    raise TypeError(
> >>   TypeError: UFunc arguments must be numarray, scalars or numeric sequences
> >>   >>> del a
> >>   >>>
> >>
> >> If I execute these statements alongside 'top' or another
> >> memory monitor, I of course see a big memory increase after
> >> each call to 'zeros', as well as a big decrease after the
> >> first 'del a' -- but no change whatsoever any more after the
> >> second 'del a', not even if I explicitly call the garbage
> >> collector via the gc module. [...]
> 
> Hmm.... Isn't this the standard python thing that it keeps the
> context of the last exception somewhere for queries? Just
> generate another exception and you should see that the memory
> taken by a is liberated because the indirect reference from
> sys.exc_traceback to a disappears.

Well, I've tried to test this, but even after multiple subsequent
exceptions the memory taken up by the numarrays is not freed, at
least not on my machine and with Python 2.3.3. Does it work for
you if you try running the above code and then generating an
exception?

BTW Todd, if you are reading this: you said in your earlier
response that you logged this bug on SourceForge somewhere, but I
can't seem to find it in what I think is the numarray bug page,
at: <http://sourceforge.net/tracker/?group_id=1369&atid=101369>.
Am I looking in the wrong place?

-- 
Leo Breebaart  <le...@ls...>

Re: [Numpy-discussion] Garbage collection fails after numarray exception

[Rob H. <ro...@ho...>]

Todd Miller wrote:
> On Tue, 2004-02-10 at 15:09, Leo Breebaart wrote:
> 
>>Hi all,
>>
>>I'm not sure if I have found a bug, or simply a type of behaviour
>>that should not have surprised me -- but I most definitely did
>>not expect the following numarray 0.8 behaviour:
>>
>>
>>   >>> import numarray
>>   >>> a = numarray.zeros(100000000)
>>   >>> del a
>>   >>> a = numarray.zeros(100000000)
>>   >>> a + ''
>>   Traceback (most recent call last):
>>     File "<stdin>", line 1, in ?
>>     File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 664, in __add__
>>       return ufunc.add(self, operand)
>>     File "/usr/lib/python2.3/site-packages/numarray/ufunc.py", line 870, in _cache_miss2
>>       (in1, in2), insig, scalar = _inputcheck(n1, n2)
>>     File "/usr/lib/python2.3/site-packages/numarray/ufunc.py", line 391, in _inputcheck    raise TypeError(
>>   TypeError: UFunc arguments must be numarray, scalars or numeric sequences
>>   >>> del a
>>   >>>
>>
>>
>>If I execute these statements alongside 'top' or another memory
>>monitor, I of course see a big memory increase after each call to
>>'zeros', as well as a big decrease after the first 'del a' -- but
>>no change whatsoever any more after the second 'del a', not even
>>if I explicitly call the garbage collector via the gc module.
>>
>>As far as I can tell, the occurrence of the exception somehow
>>causes a permanent increase in a's refcount, with a big memory
>>leak as a result.
>>
>>(In case anyone's curious about the context for this, the 
>>""" a + '' """" construct was taken straight from the Python
>>Cookbook, as a way of determining whether an object exhibits
>>string-like behaviour (useful for printing methods, etc.))
>>
>>I understand that I can easily work around this problem so that
>>numarray objects will not be fed to this construct to begin with,
>>but I do wonder if it is really true (and intended) that numarray
>>exceptions have the side effect of making certain potentially
>>huge objects indestructible.
>>
>>Can anyone here shed some light on this?
> 
> 
> It looks like a bug.  I logged it on Source Forge and I'm working on the
> solution.  

Hmm.... Isn't this the standard python thing that it keeps the context 
of the last exception somewhere for queries? Just generate another 
exception and you should see that the memory taken by a is liberated 
because the indirect reference from sys.exc_traceback to a disappears.

Rob

-- 
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/

Re: [Numpy-discussion] numarray, BLAS, LAPACK and MacOS X

[Andrea R. <ari...@pi...>]

Or you can install Numeric (and many others) via Fink without any 
effort. Look at its home page 
(<http://fink.sourceforge.net/index.php>), I'm sure you can find it 
very interesting.

Cheers,
	Andrea.

On 25 Feb 2004, at 21:45, Luc Bourhis wrote:

> MacOS X (at least 10.2 and 10.3) comes with BLAS and LAPACK already 
> installed. However the hooks in addons.py (i.e. setting the 
> environment variable USE_LAPACK and then filling the lists lapack_libs 
> and lapack_dirs) don't work because it will typically pass the 
> arguments -llapack,  -lblas to the linker although Apple does not 
> supply any liblapack.a or libblas.a. Instead Apple uses the standard 
> MacOS X distribution scheme: a framework (vecLib is the name). So the 
> correct way to compile numarray with the native blas and lapack on 
> MacOS X is to fix the addons.py as follow:
>
>     Extension('numarray.linear_algebra.lapack_lite2',
>               sourcelist,
>               include_dirs = ["Packages/LinearAlgebra2/Src", 
> 'Include/numarray'],
>               extra_objects = ["-bundle", "-framework", "vecLib",]),
>
> I checked it worked (but the -bundle may not be necessary)
>
> HtH somebody,
> -- 
> Luc Bourhis
> Chemical Crystallography Laboratory
> University of Durham

---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)

[Numpy-discussion] ImportError: undefined symbol: PyFloat_Type in _conv.so

[Tina L. <th...@bi...>]

Hello,

I'm using numarray on a RH 7.0 with Python 2.3. In my application I import
numarray like this:

    from numarray import *

and it complains:

-----------------------------
  File
"/home/thli/pymol/ext/lib/python2.3/site-packages/numarray/__init__.py",
line 11, in ?
    from numarrayall import *
  File
"/home/thli/pymol/ext/lib/python2.3/site-packages/numarray/numarrayall.py
", line 1, in ?
    from numerictypes import *
  File
"/home/thli/pymol/ext/lib/python2.3/site-packages/numarray/numerictypes.p
y", line 33, in ?
    from typeconv import typeConverters as _typeConverters
  File
"/home/thli/pymol/ext/lib/python2.3/site-packages/numarray/typeconv.py",
line 6, in ?
    import _conv
ImportError: undefined symbol: PyFloat_Type
-----------------------------

So where should I start looking to fix it? Thanks!

Tina

[Numpy-discussion] numarray, BLAS, LAPACK and MacOS X

[Luc B. <Luc...@ma...>]

MacOS X (at least 10.2 and 10.3) comes with BLAS and LAPACK already 
installed. However the hooks in addons.py (i.e. setting the environment 
variable USE_LAPACK and then filling the lists lapack_libs and 
lapack_dirs) don't work because it will typically pass the arguments 
-llapack,  -lblas to the linker although Apple does not supply any 
liblapack.a or libblas.a. Instead Apple uses the standard MacOS X 
distribution scheme: a framework (vecLib is the name). So the correct 
way to compile numarray with the native blas and lapack on MacOS X is 
to fix the addons.py as follow:

     Extension('numarray.linear_algebra.lapack_lite2',
               sourcelist,
               include_dirs = ["Packages/LinearAlgebra2/Src", 
'Include/numarray'],
               extra_objects = ["-bundle", "-framework", "vecLib",]),

I checked it worked (but the -bundle may not be necessary)

HtH somebody,
-- 
Luc Bourhis
Chemical Crystallography Laboratory
University of Durham

Re: [Numpy-discussion] RE: NA_updateDataPtr segmentation fault bug?

[Todd M. <jm...@st...>]

On Wed, 2004-02-25 at 11:34, Marco Bubke wrote:
> Ok
> 
> cdef NumArray array_to_float(NumArray array):
>   cdef NumArray new_array
>   new_array = array
>   NA_updateDataPtr(new_array)
>   NA_updateDataPtr(new_array)
>   flat_array = NA_InputArray(array, tFloat32, NUM_C_ARRAY)
>   return flat_array
> 
> Here the C code:
> 
> static PyArrayObject *__pyx_f_2gl_array_to_float(PyArrayObject *__pyx_v_array) 
> {
>   PyArrayObject *__pyx_v_new_array;
>   PyObject *__pyx_v_flat_array;
>   PyArrayObject *__pyx_r;
>   PyObject *__pyx_1 = 0;
>   Py_INCREF(__pyx_v_array);
>   ((PyObject*)__pyx_v_new_array) = Py_None; 
> Py_INCREF(((PyObject*)__pyx_v_new_array));
>   __pyx_v_flat_array = Py_None; Py_INCREF(__pyx_v_flat_array);
> 
>   /* "/home/marco/projects/calliopeia/numarray.pxd":102 */
>   Py_INCREF(((PyObject *)__pyx_v_array));
>   Py_DECREF(((PyObject *)__pyx_v_new_array));
>   ((PyObject *)__pyx_v_new_array) = ((PyObject *)__pyx_v_array);
> 
>   /* "/home/marco/projects/calliopeia/numarray.pxd":103 */
>   __pyx_1 = NA_updateDataPtr(((PyObject *)__pyx_v_new_array)); if (!__pyx_1) 
> {__pyx_filename = __pyx_f[0]; __pyx_lineno = 103; goto __pyx_L
> 1;}
>   Py_DECREF(__pyx_1); __pyx_1 = 0;

One problem is right here:  NA_updateDataPtr does not return a new
reference.  Thus,  _pyx_v_new_array/_pyx_1 is losing references right
here.

> 
>   /* "/home/marco/projects/calliopeia/numarray.pxd":104 */
>   __pyx_1 = NA_updateDataPtr(((PyObject *)__pyx_v_new_array)); if (!__pyx_1) 
> {__pyx_filename = __pyx_f[0]; __pyx_lineno = 104; goto __pyx_L
> 1;}
>   Py_DECREF(__pyx_1); __pyx_1 = 0;

And of course it's also losing them here as well.  I haven't finished
analyzing the rest of the code.  If that fix doesn't solve the problem,
let me know.

Regards,
Todd

> 
>   /* "/home/marco/projects/calliopeia/numarray.pxd":105 */
>   __pyx_1 = NA_InputArray(((PyObject *)__pyx_v_array),tFloat32,NUM_C_ARRAY); 
> if (!__pyx_1) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 105
> ; goto __pyx_L1;}
>   Py_DECREF(__pyx_v_flat_array);
>   __pyx_v_flat_array = __pyx_1;
>   __pyx_1 = 0;
> 
>   /* "/home/marco/projects/calliopeia/numarray.pxd":106 */
>   if (!__Pyx_TypeTest(__pyx_v_flat_array, __pyx_ptype_2gl__numarray)) 
> {__pyx_filename = __pyx_f[0]; __pyx_lineno = 106; goto __pyx_L1;}
>   Py_INCREF(__pyx_v_flat_array);
>   __pyx_r = (PyArrayObject *)__pyx_v_flat_array;
>   goto __pyx_L0;
> 
>   (PyObject *)__pyx_r = Py_None; Py_INCREF((PyObject *)__pyx_r);
>   goto __pyx_L0;
>   __pyx_L1:;
>   Py_XDECREF(__pyx_1);
>   __Pyx_AddTraceback("gl.array_to_float");
>   __pyx_r = 0;
>   __pyx_L0:;
>   Py_DECREF(__pyx_v_new_array);
>   Py_DECREF(__pyx_v_flat_array);
>   Py_DECREF(__pyx_v_array);
>   return ((PyArrayObject *)__pyx_r) ;
> }
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Deleting arrays.

[Andrea R. <ari...@pi...>]

I saw but it's too late. At this point I can't modify my code so 
deeply, but I'll keep your suggestion for the next project. Just for 
sake of curiosity, working with C++ arrays (I mean those defined in 
STL) would have simpliefied things?

A.

On 25 Feb 2004, at 17:32, Konrad Hinsen wrote:

> If you don't mind making it Python-specific, you can have it create 
> NumPy
> arrays directly and return them to Python. If you do want to keep it 
> "Python
> clean", then modify it in such a way that it doesn't allocate any 
> memory, but
> takes the data space of the array as input.
>
> Konrad.
>
---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)

Re: [Numpy-discussion] Deleting arrays.

[Konrad H. <hi...@cn...>]

On Wednesday 25 February 2004 16:18, Andrea Riciputi wrote:

> It could be, but how?

If you don't mind making it Python-specific, you can have it create NumPy=
=20
arrays directly and return them to Python. If you do want to keep it "Pyt=
hon=20
clean", then modify it in such a way that it doesn't allocate any memory,=
 but=20
takes the data space of the array as input.

Konrad.
--=20
-------------------------------------------------------------------------=
------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------=
------

[Numpy-discussion] RE: NA_updateDataPtr segmentation fault bug?

[Marco B. <ma...@bu...>]

Ok

cdef NumArray array_to_float(NumArray array):
  cdef NumArray new_array
  new_array = array
  NA_updateDataPtr(new_array)
  NA_updateDataPtr(new_array)
  flat_array = NA_InputArray(array, tFloat32, NUM_C_ARRAY)
  return flat_array

Here the C code:

static PyArrayObject *__pyx_f_2gl_array_to_float(PyArrayObject *__pyx_v_array) 
{
  PyArrayObject *__pyx_v_new_array;
  PyObject *__pyx_v_flat_array;
  PyArrayObject *__pyx_r;
  PyObject *__pyx_1 = 0;
  Py_INCREF(__pyx_v_array);
  ((PyObject*)__pyx_v_new_array) = Py_None; 
Py_INCREF(((PyObject*)__pyx_v_new_array));
  __pyx_v_flat_array = Py_None; Py_INCREF(__pyx_v_flat_array);

  /* "/home/marco/projects/calliopeia/numarray.pxd":102 */
  Py_INCREF(((PyObject *)__pyx_v_array));
  Py_DECREF(((PyObject *)__pyx_v_new_array));
  ((PyObject *)__pyx_v_new_array) = ((PyObject *)__pyx_v_array);

  /* "/home/marco/projects/calliopeia/numarray.pxd":103 */
  __pyx_1 = NA_updateDataPtr(((PyObject *)__pyx_v_new_array)); if (!__pyx_1) 
{__pyx_filename = __pyx_f[0]; __pyx_lineno = 103; goto __pyx_L
1;}
  Py_DECREF(__pyx_1); __pyx_1 = 0;

  /* "/home/marco/projects/calliopeia/numarray.pxd":104 */
  __pyx_1 = NA_updateDataPtr(((PyObject *)__pyx_v_new_array)); if (!__pyx_1) 
{__pyx_filename = __pyx_f[0]; __pyx_lineno = 104; goto __pyx_L
1;}
  Py_DECREF(__pyx_1); __pyx_1 = 0;

  /* "/home/marco/projects/calliopeia/numarray.pxd":105 */
  __pyx_1 = NA_InputArray(((PyObject *)__pyx_v_array),tFloat32,NUM_C_ARRAY); 
if (!__pyx_1) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 105
; goto __pyx_L1;}
  Py_DECREF(__pyx_v_flat_array);
  __pyx_v_flat_array = __pyx_1;
  __pyx_1 = 0;

  /* "/home/marco/projects/calliopeia/numarray.pxd":106 */
  if (!__Pyx_TypeTest(__pyx_v_flat_array, __pyx_ptype_2gl__numarray)) 
{__pyx_filename = __pyx_f[0]; __pyx_lineno = 106; goto __pyx_L1;}
  Py_INCREF(__pyx_v_flat_array);
  __pyx_r = (PyArrayObject *)__pyx_v_flat_array;
  goto __pyx_L0;

  (PyObject *)__pyx_r = Py_None; Py_INCREF((PyObject *)__pyx_r);
  goto __pyx_L0;
  __pyx_L1:;
  Py_XDECREF(__pyx_1);
  __Pyx_AddTraceback("gl.array_to_float");
  __pyx_r = 0;
  __pyx_L0:;
  Py_DECREF(__pyx_v_new_array);
  Py_DECREF(__pyx_v_flat_array);
  Py_DECREF(__pyx_v_array);
  return ((PyArrayObject *)__pyx_r) ;
}

Re: [Numpy-discussion] Deleting arrays.

[Andrea R. <ari...@pi...>]

It could be, but how?

On 25 Feb 2004, at 11:49, Konrad Hinsen wrote:

> If modifying the C code is an option, then it is probably the better 
> one.
>
---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)

Re: [Numpy-discussion] NA_updateDataPtr segmentation fault bug?

[Todd M. <jm...@st...>]

On Tue, 2004-02-24 at 16:37, Marco Bubke wrote:
> Hi
> 
> I have a little function in pyrex:
> 
> cdef NumArray array_to_float(NumArray array):
>   # maybe here is memoty leak!
>   cdef NumArray flat_array
>   cdef NumArray new_array
>   print 'mark 1'
>   new_array = array.astype('Float32')
>   print new_array
>   print 'mark 2'
>   NA_updateDataPtr(new_array)
>   print 'mark 3'   
>   NA_updateDataPtr(new_array)
>   print 'mark 4'  
>   flat_array = NA_InputArray(new_array, tFloat32, NUM_C_ARRAY)
>   print 'mark 5'  
>   return flat_array
> 
> After the second NA_updateDataPtr I get a segmentation fault> Otherwise I
> get it with the NA_InputArray. It goes down to getReadBufferDataPtr and
> than to 
> rval = buff2->ob_type->tp_as_buffer->bf_getreadbuffer(buff2, 0, buff);
> 
> I believe bf_getreadbuffer is memory_getbuf but I'm not sure. I don't the
> bug but its happen. 
> 
> Can somebody help me?

Maybe you could post the pyrex generated C-code and we could take a look
at that?

Regards,
Todd

> 
> thanks and regards
> 
> Marco
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id56&alloc_id438&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] User arrays in numarray

[Todd M. <jm...@st...>]

On Tue, 2004-02-24 at 02:48, Antti Korvenoja wrote:
> Dear numarray developers,
> 
> What would be the recommended class to inherit from if one wants to derive a
> new class from numarray array? In other words, what would be similar to
> UserArray in Numeric (NDArray, NumArray)?

Try subclassing NumArray.  You might want to look at PyMatrix to see a
practical example of how it can be done.  I should forewarn you that
although numarray uses new style classes,  it's sub-classibility is less
than perfect. 

Todd
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Deleting arrays.

[David M. C. <co...@ph...>]

On Tue, Feb 24, 2004 at 10:10:51PM +0100, Andrea Riciputi wrote:
> Hi,
> I'm running a simulation program partly written in C partly in Python 
> and I use Numeric arrays extensively. At the end of a single run I have 
> a bunch of Numeric arrays containing partial results that I don't need 
> anymore. These arrays have been created on the C side of my code and 
> then copied (actually linked via PyArray_FromDimsAndData) to Numeric 
> arrays. How can I release these arrays and get back memory in order to 
> be able to start the next run?

Simple answer: don't use PyArray_FromDimsAndData. Allocate your array
with Python using PyArray_FromDims, and use the data element for your C
array, instead of allocating using C and convincing Python to use that.

However, there are instances where you can't do that (the memory was
allocated by some library, for instance, that needs a custom
deallocator, or is from another array type). Then I'd suggest 

1) copying the data (depends on how much there is)
2) if the array memory was originally allocated using malloc, you set
the OWNDATA flag so Python will free it (going from memory here on the
name; check the source). Note that you should be really sure you and
Python are using the same allocator/deallocator routines.
3) or using the following trick, best described with some code:

MyOtherArrayType *A = a_library_routine_that_allocates_a_routine();
PyObject *oA = PyArray_FromDimsAndData(rank, dims, PyArray_DOUBLE,
                                      (char *)A->array_data);
PyObject *w = PyCObject_FromVoidPtr(A, free_myotherarraytype);
((PyArrayObject *)oA)->base = w;

Now, when oA is DECREF'd latter, oA->base will also be DECREF'd. Since
it's a PyCObject, free_myotherarraytype(A) will be called, free'ing the
data. Since PyArray_FromDimsAndData was used, Python won't try to
deallocate oA->data.

I haven't checked whether this works under numarray (and I'm sure I saw
a better way to do it there). I have used it for a Numeric<->Blitz++
wrapper.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Deleting arrays.

[Konrad H. <hi...@cn...>]

On Tuesday 24 February 2004 22:10, Andrea Riciputi wrote:

> anymore. These arrays have been created on the C side of my code and
> then copied (actually linked via PyArray_FromDimsAndData) to Numeric
> arrays. How can I release these arrays and get back memory in order to
> be able to start the next run?

I am not aware of any clean way. A hack that might help you out is

   array->flags |=3D OWN_DATA;

The data will then be freed when the array is released. However, there ar=
e a=20
few caveats:
1) This is not documented.
2) It works only if the data was allocated by the same memory manager tha=
t
   is used by NumPy.
3) You have to make sure that no other code keeps a reference to the data=
=2E

If modifying the C code is an option, then it is probably the better one.

Konrad.
--=20
-------------------------------------------------------------------------=
------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------=
------

[Numpy-discussion] NA_updateDataPtr segmentation fault =?iso-8859-1?q?bug=3F=0A?=

[Marco B. <ma...@bu...>]

Hi

I have a little function in pyrex:

cdef NumArray array_to_float(NumArray array):
=A0=A0#=A0maybe=A0here=A0is=A0memoty=A0leak!
=A0=A0cdef=A0NumArray=A0flat_array
=A0=A0cdef=A0NumArray=A0new_array
=A0=A0print=A0'mark=A01'
=A0=A0new_array=A0=3D=A0array.astype('Float32')
=A0=A0print=A0new_array
=A0=A0print=A0'mark=A02'
=A0=A0NA_updateDataPtr(new_array)
=A0=A0print=A0'mark=A03'=A0=A0=A0
=A0=A0NA_updateDataPtr(new_array)
=A0=A0print=A0'mark=A04'=A0=A0
=A0=A0flat_array=A0=3D=A0NA_InputArray(new_array,=A0tFloat32,=A0NUM_C_ARRAY)
=A0=A0print=A0'mark=A05'=A0=A0
=A0=A0return=A0flat_array

After the second NA_updateDataPtr I get a segmentation fault> Otherwise I
get it with the NA_InputArray. It goes down to getReadBufferDataPtr and
than to=20
rval =3D buff2->ob_type->tp_as_buffer->bf_getreadbuffer(buff2, 0, buff);

I believe bf_getreadbuffer is memory_getbuf but I'm not sure. I don't the
bug but its happen.=20

Can somebody help me?

thanks and regards

Marco

[Numpy-discussion] Deleting arrays.

[Andrea R. <ari...@pi...>]

Hi,
I'm running a simulation program partly written in C partly in Python 
and I use Numeric arrays extensively. At the end of a single run I have 
a bunch of Numeric arrays containing partial results that I don't need 
anymore. These arrays have been created on the C side of my code and 
then copied (actually linked via PyArray_FromDimsAndData) to Numeric 
arrays. How can I release these arrays and get back memory in order to 
be able to start the next run?

Thanks in advance,
	Andrea.

---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)

[Numpy-discussion] ANN: F2PY - Fortran to Python Interface Generator

[Pearu P. <pe...@ce...>]

F2PY - Fortran to Python Interface Generator
--------------------------------------------

I am pleased to announce the seventh public release of F2PY, version
2.39.235_1642. The purpose of the F2PY project is to provide the 
connection between Python and Fortran programming languages.

For more information, see

  http://cens.ioc.ee/projects/f2py2e/

Download source:

  http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz

What's new?
------------

Since the last public release, that was more than two years ago, F2PY
project has been actively maintained and many useful features have been
implemented. Here follows some highlights:

* New statement ``usercode`` allows inserting user defined C code to F2PY
  generated extension module sources at various relevant places: before
  wrapper functions, after variable declarations, and to the end of
  initialization function of the module. This makes using F2PY very
  flexible.

* New statement ``pymethoddef`` allows adding items to PyMethodDef-array.

* Full support for character arrays and arrays of strings is finally
  implemented.

* Number of feature requests from users are implemented. For example:
  - the auxiliary ``as_column_major_storage()`` that efficiently converts
    array to column storage order
  - the F2PY_REPORT_ON_ARRAY_COPY macro that when defined sends a message
    to stderr when copy of an array with the size larger than specified
    threshold is made.
  - Numarray support, thanks to Todd Miller.

* Support for Win32 and Mac OSX platforms is considerably improved. The
  list of compilers supported by the scipy_distutils package is longer
  than ever:
    GNU Fortran Compiler
    Portland Group Fortran Compiler
    Absoft Corp Fortran Compiler
    MIPSpro Fortran Compiler
    Sun|Forte Fortran 95 Compiler
    Intel Fortran Compiler for 32-bit apps
    Intel Visual Fortran Compiler for 32-bit apps
    Intel Fortran Compiler for Itanium apps
    NAGWare Fortran 95 Compiler
    Compaq Fortran Compiler
    DIGITAL|Compaq Visual Fortran Compiler
    Pacific-Sierra Research Fortran 90 Compiler
    HP Fortran 90 Compiler
    Lahey/Fujitsu Fortran 95 Compiler
    IBM XL Fortran Compiler

* Numerous bugs are fixed. You should definitely update F2PY when using
  complex input arrays, there was a nasty bug that in certain cases
  caused incorrect results.

* F2PY has now a man page and its documentation is kept up to date. Many
  other improvements to F2PY algorithm and usage are implemented, see
  HISTORY.txt for more details.

Enjoy,
	Pearu Peterson

---------------
<P><A HREF="http://cens.ioc.ee/projects/f2py2e/">F2PY 2.39.235_1642</A> -
The Fortran to Python Interface Generator (24-Feb-04)

[Numpy-discussion] I F.-.c.k yor mother :) he-he

[Danzka.danzka <dan...@ve...>]

heh :))

[Numpy-discussion] User arrays in numarray

[Antti K. <ant...@he...>]

Dear numarray developers,

What would be the recommended class to inherit from if one wants to derive a
new class from numarray array? In other words, what would be similar to
UserArray in Numeric (NDArray, NumArray)?

-Antti Korvenoja 

Re: [Numpy-discussion] copy4bytes: access beyond buffer

[Todd M. <jm...@st...>]

On Sun, 2004-02-22 at 18:51, Simon Burton wrote:
> On Mon, 23 Feb 2004 10:27:53 +1100
> Simon Burton <si...@ar...> wrote:
> 
> > I posted this bug to the sf bugs page, but it seems to have disappeared.
> > The bug remains. I've been using the CVS version. Is there anything I'm doing wrong?
> > 
> 
> OK, i think i see it now. shape=(2048,0) should be shape=(2048,). I have been using the C-API 
> aswell, and got confused.
> 
> Maybe there is a better exception to raise? Is it ever useful to have a shape=(2048,0) ?

IMHO, it's an edge case which might come up occasionally on arrays which
are intended to be resized.  Eventually I intend to fix it, but making
it work immediately isn't a priority.

> 
> Simon.
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] copy4bytes: access beyond buffer

[Todd M. <jm...@st...>]

On Sun, 2004-02-22 at 18:27, Simon Burton wrote:
> I posted this bug to the sf bugs page, but it seems to have disappeared.

numarray bugs are tracked separately from Numeric bugs.  Since Numeric
was the original project, Numeric "owns" the most easily visible
tracker, "Bugs".  numarray bugs are relocated to a less visible tracker
called "Numarray Bugs" which is accessible under the Tracker menu item, 
just to the left of "Bugs".

> The bug remains. I've been using the CVS version. Is there anything I'm doing wrong?
> 
> Python 2.2.3 (#4, Feb 15 2004, 17:40:28) 
> [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numarray
> >>> zeros = numarray.zeros( shape = (2048,0) )
> >>> zeros = zeros.astype( numarray.Int16 )
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.2/site-packages/numarray/numarraycore.py", line 594, in astype
>     ufunc._copyFromAndConvert(self, retarr)
> libnumarray.error: copy4bytes: access beyond buffer. offset=3 buffersize=0
> >>> 
> 

You're not doing anything wrong.  You're hitting an edge case which
isn't well supported in numarray yet: zero element arrays. 

> I also get this error in other situations.
> 
> Simon.
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] copy4bytes: access beyond buffer

[Simon B. <si...@ar...>]

On Mon, 23 Feb 2004 10:27:53 +1100
Simon Burton <si...@ar...> wrote:

> I posted this bug to the sf bugs page, but it seems to have disappeared.
> The bug remains. I've been using the CVS version. Is there anything I'm doing wrong?
> 

OK, i think i see it now. shape=(2048,0) should be shape=(2048,). I have been using the C-API 
aswell, and got confused.

Maybe there is a better exception to raise? Is it ever useful to have a shape=(2048,0) ?

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

[Numpy-discussion] copy4bytes: access beyond buffer

[Simon B. <si...@ar...>]

I posted this bug to the sf bugs page, but it seems to have disappeared.
The bug remains. I've been using the CVS version. Is there anything I'm doing wrong?

Python 2.2.3 (#4, Feb 15 2004, 17:40:28) 
[GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numarray
>>> zeros = numarray.zeros( shape = (2048,0) )
>>> zeros = zeros.astype( numarray.Int16 )
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/site-packages/numarray/numarraycore.py", line 594, in astype
    ufunc._copyFromAndConvert(self, retarr)
libnumarray.error: copy4bytes: access beyond buffer. offset=3 buffersize=0
>>> 

I also get this error in other situations.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] "GC object already in linked list" error when testall.test()

[Todd M. <jm...@st...>]

On Fri, 2004-02-20 at 10:49, Tina Li wrote:
> Hello,
> 
> I installed numarray on a RedHat 8.0 with Python 2.2.1. The build completed
> fine, but it failed when I tried to testall.test(). Here is the output:
> 
> ------------------------------------------------------------
> Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
> [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numarray.testall as testall
> >>> testall.test()
> numarray:                               ((0, 1142), (0, 1142))
> numarray.records:                       (0, 48)
> numarray.strings:                       (0, 168)
> numarray.memmap:                        (0, 82)
> numarray.objects:                       (0, 68)
> numarray.memorytest:                    (0, 16)
> Fatal Python error: GC object already in linked list
> Aborted
> ------------------------------------------------------------
> 
> Seems like a garbage collector problem. That's all I can tell. I installed
> using "python setup.py install --gencode --prefix=<installation directory>"
> and then "export PYTHONPATH". Does anyone have a clue how this can be fixed?

Python-2.2.3 and Python-2.3.3 both (seem to) work fine, so I suggest
upgrading to one of those.

I've had no problem reproducing this bug,  but solving it is another
matter.

Regards,
Todd

-- 
Todd Miller <jm...@st...>

[Numpy-discussion] "GC object already in linked list" error when testall.test()

[Tina L. <th...@bi...>]

Hello,

I installed numarray on a RedHat 8.0 with Python 2.2.1. The build completed
fine, but it failed when I tried to testall.test(). Here is the output:

------------------------------------------------------------
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numarray.testall as testall
>>> testall.test()
numarray:                               ((0, 1142), (0, 1142))
numarray.records:                       (0, 48)
numarray.strings:                       (0, 168)
numarray.memmap:                        (0, 82)
numarray.objects:                       (0, 68)
numarray.memorytest:                    (0, 16)
Fatal Python error: GC object already in linked list
Aborted
------------------------------------------------------------

Seems like a garbage collector problem. That's all I can tell. I installed
using "python setup.py install --gencode --prefix=<installation directory>"
and then "export PYTHONPATH". Does anyone have a clue how this can be fixed?

Thanks!

Tina