[Numpy-discussion] numpy.trapz() doesn't respect subclass

Ryan May rmay31 at gmail.com
Sat Mar 27 23:37:23 EDT 2010

On Sat, Mar 27, 2010 at 8:23 PM,  <josef.pktd at gmail.com> wrote:
> Matrices have been part of numpy for a long time and your patch would
> break backwards compatibility in a pretty serious way.

Yeah, and I should admit that I realize that makes this particular
patch a no-go. However, that to me doesn't put the issue to bed for
any future code that gets written (see below).

> subclasses of ndarray, like masked_arrays and quantities, and classes
> that delegate to array calculations, like pandas, can redefine
> anything. So there is not much that can be relied on if any subclass
> is allowed to be used inside a function
> e.g. quantities redefines sin, cos,...
> http://packages.python.org/quantities/user/issues.html#umath-functions
> What happens if you call fft with a quantity array?

Probably ends up casting to an ndarray. But that's a complex operation
that I can live with not working. It's coded in C and can't be
implemented quickly using array methods. And in this

> Except for simple functions and ufuncs, it would be a lot of work and
> fragile to allow asanyarray. And, as we discussed in a recent thread
> on masked arrays (and histogram), it would push the work on the
> function writer instead of the ones that are creating new subclasses.

I disagree in this case.  I think the function writer should only be
burdened to try to use array methods rather than numpy functions, if
possible, and avoiding casts other than asanyarray() at all costs.  I
think we shouldn't be scared of getting an error when a subclass is
passed to a function, because that's an indication to the programmer
that it doesn't work with what you're passing in and you need to
*explicitly* cast it to an ndarray. Having the function do the cast
for you is: 1) magical and implicit 2) Forces an unnecessary cast on
those who would otherwise work fine. I get errors when I try to pass
structured arrays to math functions, but I don't see numpy casting
that away.

> Of course, the behavior in numpy and scipy can be improved, and trapz
> may be simple enough to change, but I don't think a patch that breaks
> backwards compatibility pretty seriously and is not accompanied by
> sufficient tests should go into numpy or scipy.

If sufficient tests is the only thing holding this back, let me know.
I'll get to coding.

But I can't argue with the backwards incompatibility. At this point, I
think I'm more trying to see if there's any agreement that: casting
*everyone* because some class breaks behavior is a bad idea.  The
programmer can always make it work by explicitly asking for the cast,
but there's no way for the programmer to ask the function *not* to
cast the data. Hell, I'd be happy if trapz took a flag just telling it

> (On the other hand, I'm very slowly getting used to the pattern that
> for a simple function, 10% is calculation and 90% is interface code.)

Yeah, it's kind of annoying, since the 10% is the cool part you want,
and that 90% is thorny to design and boring to code.


Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

More information about the NumPy-Discussion mailing list