[Numpy-discussion] questions about a "complicated" user-defined dtype and the ufunc API
Thu Aug 26 22:43:07 CDT 2010
On Thu, Aug 26, 2010 at 5:09 PM, Nathaniel Smith <firstname.lastname@example.org> wrote:
> On Mon, Aug 23, 2010 at 9:20 AM, Travis Oliphant <email@example.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
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 ?
More information about the NumPy-Discussion