[SciPy-user] scipy_core bug in where

Fernando Perez 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 mailing list