[Pyrex] Re: Pyrex and Numarray

[Nitin Madnani]

Hmm ... this looks good. A couple of questions:

1) numarray is slower than Numeric for arrays smaller than, say,  
20,000 elements right?
2) Is this filling-in using the C functions going to be faster than  
using the Pythonic way to create a numeric array
and then filling it in, as Greg and the others suggested earlier?

Thanks !
Nitin

On Sep 20, 2005, at 5:34 AM, John Carter wrote:

> I've never had any problems doing this.
>
> I have declared a _numarray object which
>
>
> cdef extern from "numarray/arraybase.h":
>     cdef enum NumarrayType:
>         tAny, tBool, tInt8, tUInt8, tInt16, tUInt16, tInt32,  
> tUInt32, tInt64, tUInt64, tFloat32, tFloat64, tComplex32, tComplex64
>
> cdef extern from "numarray/arrayobject.h":
>     struct PyArray_Descr:
>         int type_num
>         int elsize
>         char type
>
> cdef extern from "numarray/arrayobject.h":
>     ctypedef class numarray._numarray._numarray [object  
> PyArrayObject]:
>         cdef char *data
>         cdef int nd
>         cdef int *dimensions
>         cdef int *strides
>         cdef object base
>         cdef PyArray_Descr *descr
>
> cdef extern from "numarray/arrayobject.h":
>     cdef object PyArray_FromDimsAndData(int nd, int *dims, int  
> type, char *data)
>     cdef object PyArray_FromDims(int nd, int *dims, int type)
>     cdef object PyArray_Return(object)
>
>
> I can use with
>
> cdef extern from "numarray/libnumarray.h":
>     # The numarray initialization funtion
>     void import_libnumeric()
>
> # The Numeric API requires this function to be called before
> # using any Numeric facilities in an extension module.
> import_libnumeric()
>
>
>
> cdef _numarray out
>
> then I use the nunarray api to fill it.
>
>   out = PyArray_FromDims(left.nd, left.dimensions, tUInt8)
>
> then I can use the constructs
>
> out.nd, out.dimensions, out.strides, out.data
>
> to access the internals.
>
> this is great but what I really want to do is, given a,b,c,d,e as  
> numarray's I want to write
>
> a = (c+b)*(d-e)
>
> and have pyrex generate efficient C code that dosnt create  
> intermediate arrays.
>
> I'm sure  I can do this if a .. e are PyObjects by going back to  
> the python level. But that seems to defeat the idea of numerical  
> efficiency.
>
> I ran an undergraduate project about 3 years ago (pyrex was about  
> 0.4) which did this but it wasn't really useable,as he totally  
> hijacked the [] notation and lists and stuff stopped working.
>
> I'm considering having another go (or rather getting an  
> undergraduate), but I cant decide on the approach:
> Use a preprocessor to generate pyrex,
> Hack pyrex internals
> or wait till pyrex does objects and hope that the object  
> implementation will be sufficiently flexible to let me do what I want.
>
> I'm currently leaning on the first option, even if it means parsing  
> the pyrex file twice.
>
> John
>
>
>
>
>
> Dr. John N. Carter   jnc at ecs.soton.ac.uk
> ISIS                        http://www.ecs.soton.ac.uk/~jnc/
>
> _______________________________________________
> Pyrex mailing list
> Pyrex at lists.copyleft.no
> http://lists.copyleft.no/mailman/listinfo/pyrex
>