[SciPy-user] scipy_core bug in where
Fernando.Perez at colorado.edu
Thu Nov 17 23:12:05 CST 2005
Travis Oliphant wrote:
>>First, I was a little surprised that a.max() was type int32 rather than
>>int16 (which causes the result to have dtype int32), but then a is
>>clearly be misinterpreted.
> Thanks for catching the bug. We'll look into it.
> By the way, you can reduce in the type int16 if you
> need to using a.max(rtype=int16) -- This was recently changed from
> that default to avoid a different kind of surprise (wrap around effects).
> This usage makes me regret somewhat the switch.
I still think that for accumulators (things like sum/prod), getting rid of the
wrap around bug is the right decision. But things like min/max can, by
definition, never overflow. Are you using the same internal machinery for
both, so that distinguishing between 'things that can overflow' and things
that can't forces an extra code path/slowdown? Would it be possible to
resolve this at the top level code, so that no if statements need to be
introduced in every evaluation?
Sorry for being a little vague, but I just don't know that code well enough to
word things more precisely. Still, I think that giving users a reliable
a.sum() was a good thing.
More information about the SciPy-user