[Numpy-discussion] field names on numpy arrays

[Pierre GM]

On Jun 4, 2009, at 3:12 PM, Fernando Perez wrote:

> Howdy,
> I was thinking about this yesterday,  because I'm dealing with exactly
> this same problem in a local  project.  How hard would it be to allow
> structured arrays to support ufuncs/arithmetic for the case where
> their dtype is actually a composite of the same 'native' ones?
> Basically, for cases where one could manually make a flattened view
> using the 'base' dtype, do the operation, and repack the output into
> the structured dtype, perhaps numpy could support it natively?

I foresee serious disturbance in the force...
When I use structured arrays, each field usually represents a  
different variable, and I may not be keen on having a same operation  
applied to all variables. At least, the current behavior (raise an  
exception) forces me to think twice.

Now, I'm not saying that it could not be useful in some cases. For  
example, I may want to have a (n,12) array of monthly data, with one  
field for each month. Then, having the possibility to apply the same  
operation to all fields would be great. I still think it's a  
particular case.


> I can see there being a small cost to this,  but the check could be
> very fast, because the information on whether a given dtype is in fact
> a composite of identical native ones or not can be stored statically,
> at construction time, in the dtype object itself.  That way,  at
> runtime, the ufunc/arithmetic machinery only needs to check this
> static flag, and if it's true, it can take the (slightly slower) path
> of (flatten,operate,repack) instead of bailing out with an error as it
> does today.

What about the case where you multiply a 1D structured array with a nD  
array ? What should you have ?