[Numpy-discussion] suggestion for generalizing numpy functions

Darren Dale dsdale24@gmail....
Sun Mar 15 09:46:30 CDT 2009


Hi Travis,

On Mon, Mar 9, 2009 at 6:08 PM, Travis E. Oliphant
<oliphant@enthought.com>wrote:

> Darren Dale wrote:
> > On Mon, Mar 9, 2009 at 9:50 AM, Darren Dale <dsdale24@gmail.com
> > <mailto:dsdale24@gmail.com>> wrote:
> >
> >     I spent some time over the weekend fixing a few bugs in numpy that
> >     were exposed when attempting to use ufuncs with ndarray
> >     subclasses. It got me thinking that, with relatively little work,
> >     numpy's functions could be made to be more general. For example,
> >     the numpy.ma <http://numpy.ma> module redefines many of the
> >     standard ufuncs in order to do some preprocessing before the
> >     builtin ufunc is called. Likewise, in the units/quantities package
> >     I have been working on, I would like to perform a dimensional
> >     analysis to make sure an operation is allowed before I call a
> >     ufunc that might change data in place.
> >
>
> The suggestions behind this idea are interesting.   It seems related to
> me, to the concept of "contexts" that Eric presented at SciPy a couple
> of years ago that keeps coming up at Enthought.    It may be of benefit
> to solve the problem from that perspective rather than the "sub-class"
> perspective.
>
> Unfortunately, I don't have time to engage this discussion as it
> deserves, but I wanted to encourage you because I think there are good
> ideas in what you are doing.    The sub-class route may be a decent
> solution, but it also might be worthwhile to think from the perspective
> of contexts as well.
>
> Basically, the context idea is that rather than "sub-class" the ndarray,
> you create a more powerful name-space for code that uses arrays to live
> in.   Because python code can execute using a namespace that is any
> dictionary-like thing, you can create a "namespace" object with more
> powerful getters and setters that intercepts the getting and setting of
> names as the Python code is executing.
>
> This allows every variable to be "adapted" in a manner analagous to
> "type-maps" in SWIG --- but in a more powerful way.    We have been
> taking advantage of this basic but powerful idea quite a bit.
> Unit-handling is a case where "contexts" and generic functions rather
> than sub-classes appears to be an approach  to solving the problem.
>
> The other important idea about contexts is that you can layer-on
> adapters on getting and setting variables into the namespace which
> provide more hooks for doing some powerful things in easy-to-remember
> ways.
>
> I apologize if it sounds like I'm hi-jacking your question to promote an
> agenda.   I really like the generality you are trying to reach with your
> suggestions and just wanted to voice the opinion that it might be better
> to look for a solution using the two dimensions of "objects" and
> "namespaces" (o.k.  generic functions are probably another dimension in
> my metaphor) rather than just sub-classes of objects.
>

Contexts may be an alternative approach, but I do not understand the vision
or how they would be applied to the problem of unit handling.

The Quantities package is already in a useful and working state, based on an
ndarray subclass. My goal at this point is to make quantities more useful
with numpy/scipy. There is already a mechanism for doing so, it just needs
to be tweaked in order for it to more generally applicable.

Hopefully I can interest some of the current numpy developers to engage in
the discussion after 1.3 is released.

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20090315/596c463a/attachment.html 


More information about the Numpy-discussion mailing list