[Numpy-discussion] Warnings in numpy.ma.test()

[Pierre GM]

On Mar 17, 2010, at 9:16 PM, Charles R Harris wrote:
> 
> 
> On Wed, Mar 17, 2010 at 7:39 PM, Darren Dale <dsdale24 at gmail.com> wrote:
> On Wed, Mar 17, 2010 at 8:22 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> > What bothers me here is the opposing desire to separate ufuncs from their
> > ndarray dependency, having them operate on buffer objects instead. As I see
> > it ufuncs would be split into layers, with a lower layer operating on buffer
> > objects, and an upper layer tying them together with ndarrays where the
> > "business" logic -- kinds, casting, etc -- resides. It is in that upper
> > layer that what you are proposing would reside. Mind, I'm not sure that
> > having matrices and masked arrays subclassing ndarray was the way to go, but
> > given that they do one possible solution is to dump the whole mess onto the
> > subtype with the highest priority. That subtype would then be responsible
> > for casts and all the other stuff needed for the call and wrapping the
> > result. There could be library routines to help with that. It seems to me
> > that that would be the most general way to go. In that sense ndarrays
> > themselves would just be another subtype with especially low priority.
> 
> I'm sorry, I didn't understand your point. What you described sounds
> identical to how things are currently done. What distinction are you
> making, aside from operating on the buffer object? How would adding a
> method to modify the input to a ufunc complicate the situation?
> 
> 
> Just *one* function to rule them all and on the subtype dump it. No __array_wrap__, __input_prepare__, or __array_prepare__, just something like __handle_ufunc__. So it is similar but perhaps more radical. I'm proposing having the ufunc upper layer do nothing but decide which argument type will do all the rest of the work, casting, calling the low level ufunc base, providing buffers, wrapping, etc. Instead of pasting bits and pieces into the existing framework I would like to lay out a line of attack that ends up separating ufuncs into smaller pieces that provide low level routines that work on strided memory while leaving policy implementation to the subtype. There would need to be some default type (ndarray) when the functions are called on nested lists and scalars and I'm not sure of the best way to handle that.
> 
> I'm just sort of thinking out loud, don't take it too seriously.

Still, I like it. It sounds far cleaner than the current Harlequin's costume approach. 
In the thinking out loud department: 
* the upper layer should allow the user to modify the input on the fly (a current limitation of __array_prepare__), so that we can change values that we know will give invalid results before the lower layer processes them.
* It'd be nice to have the domains defined in the functions. Right now, the domains are defined in numpy.ma.core for unary and binary functions. Maybe we could extend the 'context' of each ufunc ?