[Numpy-discussion] convert to numarray

Todd Miller jmiller at stsci.edu
Mon Jun 9 06:41:02 EDT 2003

On Sun, 2003-06-08 at 14:38, Pete Shinners wrote:
> still there are a few things i am 
> doing that i'm unsure if numarray is ready to handle yet?
> what is going to make this tricky is i'm doing a bit of 'attribute 
> mangling' to the Numeric array structure. this is necessary as the image 
> data is extremely 'non-flat'. also, since i am referencing data held in 
> another python object, i need to make sure the array holds a reference 
> to the original object. these are the things i'm afraid i'll be stuck on.
> here is pretty much what i am doing now, simplified quite a bit...
> PyObject* pixelsarray(SDL_Surface *surf)
> {
>      int dim[3];
>      PyObject *array;
>      dim[0] = surf->w;
>      dim[1] = surf->h;
>      dim[2] = 3;
>      array = PyArray_FromDimsAndData(3, dim,
>          PyArray_UBYTE, surf->pixels);
>      if(array)
>      {
>          PyArrayObject *a = (PyArrayObject*)array
>          a->flags = OWN_DIMENSIONS|OWN_STRIDES;
>          a->strides[2] = 1;
>          a->strides[1] = surf->pitch;
>          a->strides[0] = surf->format->BytesPerPixel;
>          a->base = _pyobject_to_surf_;
>      }
>      return array;
> }
> note that depending on pixel packing and endianess, the strides[2] can 
> become -1. smiley. 

Despite old documentation to the contrary,  the strides array is now
writable.  The -1 is more problematic.  Anytime a ufunc is called, 
there is "safety code" which evaluates the shape, strides, byteoffset,
buffer base and buffer size to ensure that the ufunc won't attempt an
access outside the buffer or generate a misaligned pointer.  negative
strides are possible *provided* that the byteoffset is chosen so that
everything works out.

> also pretend a->base is pointing to a real python 
> object, which it does in the real version.

numarray has a "base" pointer which is currently unused and intended for
the purpose of backward compatibility.  Since numarray does not yet use
the base pointer at all, it does not deallocate it at array destruction

> there is likely a way to workaround the "base" requirement with weakrefs 
> i suppose, but i'd rather not jump through the extra hoops. the real 
> necessity is setting the strides how i want. i didn't see any array 
> creation functions that allow me to pick my own strides. 

New in numarray-0.5 is the API function NA_NewAllStrides which allows
you to pass in a pointer to a strides array.  NA_NewAllStrides does not
currently check the validity of the strides array.

> once i create 
> the array here i never change any of the array attributes.
> if this looks doable then it's time for me to sit down with the numarray 
> docs and see what new and exciting things await me :]

It looks close to doable to me.  There are probably still a few loose

Todd Miller 			jmiller at stsci.edu

More information about the NumPy-Discussion mailing list