Jonathan Wang wrote:
> On 10/26/06, *Travis Oliphant* <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     > Okay, is my understanding here correct? I am defining two type
>     > descriptors:
>     > PyArray_Descr mxNumpyType - describes the Numpy array type.
>     > PyTypeObject mxNumpyDataType - describes the data type of the
>     contents
>     > of the array (i.e. mxNumpyType->typeobj points to this),
>     inherits from
>     > PyDoubleArrType_Type and overrides some fields as mentioned above.
>     >
>     The nomenclature is that mxNumPyType is the data-type of the array and
>     your PyTypeObject is the "type" of the elements of the array.  
>     So, you
>     have the names a bit backward.
>
>     So, to correspond with the way I use the words "type" and
>     "data-type", I
>     would name them:
>
>     PyArray_Descr mxNumpyDataType
>     PyTypeObject mxNumpyType
>
>
> Okay, I will use this convention going forwards.
>
>     > And the getitem and setitem functions are designed to only
>     give/take
>     > PyObject* of type mxDateTime.
>     >
>     These are in the 'f' member of the PyArray_Descr structure, so
>     presumably you have also filled in your PyArray_Descr structure with
>     items from PyArray_DOUBLE?
>
>
> That's correct. I have all members of the 'f' member identical to that 
> from PyArray_DOUBLE, except:
>
>     mxNumpyType->f->dotfunc = NULL;
>     mxNumpyType->f->getitem = date_getitem;
>     mxNumpyType->f->setitem = date_setitem;
>     mxNumpyType->f->cast[PyArray_DOUBLE] = (PyArray_VectorUnaryFunc*) 
> dateToDouble;
>     mxNumpyType->f->cast[PyArray_OBJECT] = (PyArray_VectorUnaryFunc*) 
> dateToObject;
>
> All other cast functions are NULL.
>
> If I redefine the string function, I encounter another, perhaps more 
> serious problem leading to a segfault. I've defined my string function 
> to be extremely simple:
> >>> def printer(arr):
> ...   return str(arr[0])
>
> Now, if I try to print an element of the array:
> >>> mxArr[0]
>
> I get to this stack trace:
> #0  scalar_value (scalar=0x814be10, descr=0x5079e0) at 
> scalartypes.inc.src:68
> #1  0x0079936a in PyArray_Scalar (data=0x814cf98, descr=0x5079e0, 
> base=0x814e7a8) at arrayobject.c:1419
> #2  0x007d259f in array_subscript_nice (self=0x814e7a8, op=0x804eb8c) 
> at arrayobject.c:1985
> #3  0x00d17dde in PyObject_GetItem (o=0x814e7a8, key=0x804eb8c) at 
> Objects/abstract.c:94
>
> (Note: for some reason gdb claims that arrayobject.c:1985 is 
> array_subscript_nice, but looking at my source this line is actually 
> in array_item_nice. *boggle*)
>
> But scalar_value returns NULL for all non-native types. So, destptr in 
> PyArray_Scalar is set to NULL, and the call the copyswap segfaults.
>
> Perhaps scalar_value should be checking the scalarkind field of 
> PyArray_Descr, or using the elsize and alignment fields to figure out 
> the pointer to return if scalarkind isn't set?

Hmmm... It looks like the modifications to scalar_value did not take 
into account user-defined types.  I've added a correction so that 
user-defined types will use setitem to set the scalar value into the 
array.  Presumably your setitem function can handle setting the array 
with scalars of your new type?

I've checked the changes into SVN.


-Travis


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Reply via email to