On Thu, Jun 4, 2009 at 12:28 PM, Pierre GM<[email protected]> wrote: > 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.
My main use case is really arithmetic: being able to take differences of structured arrays that contain similar data would make some of our code here clearer. But if this doesn't fly, I can always have a little subtract(a,b) helper that does the 'unpack, subtract,repack' dance for 'a-b' and similar for any other needed operations. I realize it's not the most generic case, but we're using structured arrays a lot for putting data in more manageable/comprehensible structures, and some basic arithmetic support on the whole array would be nice sometimes. The other alternative is to do field-by-field extractions and operations, which is unnecessary when all the fields happen to have the exact same kind of data (numerically speaking, not conceptually). > What about the case where you multiply a 1D structured array with a nD > array ? What should you have ? I'd punt. I think it's OK for structured arrays not to support the full range of binary operations and ufuncs, I was only thinking of allowing the very simplest: binary ops between absolutely identical (shape, dtype) arrays whose dtype is an aggregation of native ones for which the 'unpack, operate, repack' pattern works. It seems to me like an improvement in the functionality of structured arrays, but it's not a big deal. Cheers, f _______________________________________________ Numpy-discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
