[Numpy-discussion] questions about a "complicated" user-defined dtype and the ufunc API

[Sebastian Haase]

On Thu, Aug 26, 2010 at 5:09 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Mon, Aug 23, 2010 at 9:20 AM, Travis Oliphant <oliphant at enthought.com> wrote:
>> On Aug 22, 2010, at 4:36 PM, Nathaniel Smith wrote:
>>> Question 2: Am I missing something, or does the ufunc API make this
>>> impossible? The problem is that a "PyUFuncGenericFunction" doesn't
>>> have any way to find the dtypes of the arrays that it's working on.
>>> All of the PyArray_ArrFuncs functions take a pointer to the underlying
>>> ndarray as an argument, so that when working with a string or void
>>> array, you can find the actual dtype and figure out (e.g.) the size of
>>> the objects involved. But ufunc inner loops don't get that, so I guess
>>> it's just impossible to define a ufunc over variable-sized data, or
>>> data that you need to be able to see the dtype metadata to interpret?
>>
>> Yes, currently that is correct.   Variable data-types don't work in ufuncs for some subtle reasons.  But, the changes that allow date-times to work also fix (or will fix) this problem as a side-effect.
>>
>> The necessary changes to ufuncs have not been made, yet, however.   They are planned.   And, yes, this would allow ufuncs to be used for string equality testing, etc.
>
> Okay, thanks. It sounds like I'll need to accomplish what I want in
> some other way for now, then, but if I get some surplus time somehow
> then maybe I'll take a crack at the "proper" solution :-).
>
> -- Nathaniel

Hi,
Is this discussion at all related to ticket #450 (
http://projects.scipy.org/numpy/ticket/450 )  ?
(( a[1:,1:,1:].min()  is creating temporary copy of (potentially
large) array a, if non-contiguous ))
IOW, can methods be ufunc, and hence take care of memory layout complications ?

-S.