John Hunter | 2 Oct 20:32 2002

calling multiarraymodule.c funcs from c api

I am new to numpy extension writing, and am trying to call some of the
functions defined in Numeric-21.3/Src/multiarraymodule.c, eg

  extern PyObject *PyArray_Correlate(PyObject *op1, PyObject *op2, int mode) 

in a Numeric extension module that I am writing.  

Are these functions available via the C API, and if so, how should I
go about accessing them?  Or are the only array functions defined in
Include/arrayobject.h available in the C API?

Below is my prototype module.  I am defining a function 'xcorr' that
just does what cross_correlate does, as a test case to see if I can
access the multiarray C API:

/* jdhscipy.c	--  Wed Oct  2 2002
 */

#include "Python.h"
#include "Numeric/arrayobject.h"
#include "stdio.h"

static PyObject *ErrorObject;
extern PyObject *PyArray_Correlate(PyObject*, PyObject*, int);

static char xcorr__doc__[] = "";

static PyObject * xcorr(PyObject *self, PyObject *args) { 
    PyObject *shape, *a0;
    int mode=0;
(Continue reading)

Nils Wagner | 4 Oct 12:58 2002
Picon

numarray via CVS

Hi,

I tried to install numarray via latest CVS. However 
python setup.py install failed 

This is the output

Src/_ndarraymodule.c:240: warning: `_ndarray_bytestride_set' defined but
not use                         d
Src/_ndarraymodule.c:260: warning: `_ndarray_byteoffset_get' defined but
not use                         d
Src/_ndarraymodule.c:266: warning: `_ndarray_byteoffset_set' defined but
not use                         d
Src/_ndarraymodule.c:288: warning: `_ndarray_aligned_get' defined but
not used
Src/_ndarraymodule.c:294: warning: `_ndarray_aligned_set' defined but
not used
Src/_ndarraymodule.c:323: warning: `_ndarray_contiguous_get' defined but
not use                         d
Src/_ndarraymodule.c:329: warning: `_ndarray_contiguous_set' defined but
not use                         d
error: command 'gcc' failed with exit status 1

Any suggestion ?

Nils

Nils

(Continue reading)

Todd Miller | 4 Oct 15:25 2002

Re: numarray via CVS

  Nils Wagner wrote:

>Hi,
>
>I tried to install numarray via latest CVS. However 
>python setup.py install failed 
>
>This is the output
>
>Src/_ndarraymodule.c:240: warning: `_ndarray_bytestride_set' defined but
>not use                         d
>Src/_ndarraymodule.c:260: warning: `_ndarray_byteoffset_get' defined but
>not use                         d
>Src/_ndarraymodule.c:266: warning: `_ndarray_byteoffset_set' defined but
>not use                         d
>Src/_ndarraymodule.c:288: warning: `_ndarray_aligned_get' defined but
>not used
>Src/_ndarraymodule.c:294: warning: `_ndarray_aligned_set' defined but
>not used
>Src/_ndarraymodule.c:323: warning: `_ndarray_contiguous_get' defined but
>not use                         d
>Src/_ndarraymodule.c:329: warning: `_ndarray_contiguous_set' defined but
>not use                         d
>error: command 'gcc' failed with exit status 1
>
>
>Any suggestion ?
>
>Nils
>
(Continue reading)

Andrew P. Lentvorski | 7 Oct 04:16 2002

int and float ufunc?

Could someone explain the reason why int() and float() don't work as
ufuncs?  Is it just that someone needs to write the code, or is there some
subtlety at work that I am missing?

It took a bit of digging to go find the fact that what I wanted is
newarray = oldarray.astype(MagicNewTypeCode)

Thanks,
-a

Travis Oliphant | 7 Oct 08:26 2002

Re: int and float ufunc?

> Could someone explain the reason why int() and float() don't work as
> ufuncs?  Is it just that someone needs to write the code, or is there some
> subtlety at work that I am missing?

What would you have them do?  Their current definition works for returning
suitable arrays as integers and floats respectively, just as the Python
documentation says these two functions should.

It would be an easy thing to map int() to oldarray.astype(Int) and so
forth but is this a good policy.  I submit it is not.

-Travis O.

Andrew P. Lentvorski | 7 Oct 10:42 2002

Re: int and float ufunc?

On Mon, 7 Oct 2002, Travis Oliphant wrote:

> > Could someone explain the reason why int() and float() don't work as
> > ufuncs?  Is it just that someone needs to write the code, or is there some
> > subtlety at work that I am missing?
>
> What would you have them do?  Their current definition works for returning
> suitable arrays as integers and floats respectively, just as the Python
> documentation says these two functions should.

Okay, now I'm really confused ...

>>> import Numeric
>>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
>>> a
array([ 1.5,  2.5,  3.5])
>>> int(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: Only rank-0 arrays can be converted to Python scalars.

I guess I'm really dense, but how does that result constitute a definition
that "works"?  Has this behavior changed recently such that I should
update my version of Numeric?  If so, that would be a wonderful solution
to my problem (explained below).

> It would be an easy thing to map int() to oldarray.astype(Int) and so
> forth but is this a good policy.  I submit it is not.

I could be persuaded either way.  I was simply wondering what the
(Continue reading)

Todd Miller | 7 Oct 13:39 2002

arange(-10)

The subject line contains what I consider to be an invalid range 
expression.   Numarray, now and always, reacts badly to it.  Currently, 
numarray tries to allocate a multi-gigabyte array.   In the past, it has 
dumped core.

The question is, what should it do?

1. raise ValueError, "Invalid negative range expression"     (my +1)
2. zeros((0,), 'l')                                                     
                  (Numeric does this)

Is there a good justification to keep the existing Numeric behavior? 
 Any other suggestions?

Todd

Pearu Peterson | 7 Oct 14:25 2002
Picon
Picon

Re: arange(-10)

On Mon, 7 Oct 2002, Todd Miller wrote:

> The subject line contains what I consider to be an invalid range 
> expression.   Numarray, now and always, reacts badly to it.  Currently, 
> numarray tries to allocate a multi-gigabyte array.   In the past, it has 
> dumped core.
> 
> The question is, what should it do?
> 
> 1. raise ValueError, "Invalid negative range expression"     (my +1)
> 2. zeros((0,), 'l')                                                     
>                   (Numeric does this)
> 
> Is there a good justification to keep the existing Numeric behavior? 
>  Any other suggestions?

Does Numarray support empty arrays? If yes, I'd vote for Python behavior:

>>> range(-10)
[]

Otherwise, the case 1.

Hmm, according to Numeric.arange docs, "arange is just like
range() except it returns an array whose type can be specified ...".
But given example shows that there are other (undocumented?) exceptions
when comparing arange and range.

Pearu

(Continue reading)

Pearu Peterson | 7 Oct 14:42 2002
Picon
Picon

Re: int and float ufunc?

On Mon, 7 Oct 2002, Andrew P. Lentvorski wrote:

> On Mon, 7 Oct 2002, Travis Oliphant wrote:
> 
> > What would you have them do?  Their current definition works for returning
> > suitable arrays as integers and floats respectively, just as the Python

    ^^^^^^^^^^^^^^^

> > documentation says these two functions should.
> 
> Okay, now I'm really confused ...
> 
> >>> import Numeric
> >>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
> >>> a
> array([ 1.5,  2.5,  3.5])
> >>> int(a)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: Only rank-0 arrays can be converted to Python scalars.

                  ^^^^^^^^^^^^^

> I guess I'm really dense, but how does that result constitute a definition
> that "works"?

See ^^^ above. In this case, suitable arrays are rank-0 arrays. So, the
definition works (see also below).

(Continue reading)

Travis Oliphant | 7 Oct 17:50 2002

Re: int and float ufunc?

On Mon, 7 Oct 2002, Andrew P. Lentvorski wrote:

> On Mon, 7 Oct 2002, Travis Oliphant wrote:
>
> > > Could someone explain the reason why int() and float() don't work as
> > > ufuncs?  Is it just that someone needs to write the code, or is there some
> > > subtlety at work that I am missing?
> >
> > What would you have them do?  Their current definition works for returning
> > suitable arrays as integers and floats respectively, just as the Python
> > documentation says these two functions should.
>
> Okay, now I'm really confused ...
>
> >>> import Numeric
> >>> a = Numeric.array([1.5, 2.5, 3.5], Numeric.Float64)
> >>> a
> array([ 1.5,  2.5,  3.5])
> >>> int(a)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: Only rank-0 arrays can be converted to Python scalars.
>

I didn't mean to confuse you.  I said "suitable" arrays.  Returning a
single Python integer from an array doesn't really make sense unless that
array is 0-dimensional (rank-0).  Now, one could argue that an array of
length 1 could also be converted unambiguously, but that discussion has
never taken place.

(Continue reading)


Gmane