[SciPy-user] operations on int8 arrays
gpajer at rider.edu
Wed Oct 19 16:13:10 CDT 2005
Fernando Perez wrote:
>Travis Oliphant wrote:
>>Or, this could simply be the default when calling the .sum method (which
>>is add.reduce under the covers). The reduce method could stay with the
>>default of the integer type.
>>Obviously, it's going to give "unexpected" results to somebody.
>>Automatic upcasting can have its downsides. But, perhaps in this case
>>(integer reductions), it is better to do the upcasting. What do people
>I've personally always been of the opinion that accumulator methods are one
>case where automatic upcasting is justified. Since not doing it is almost
>guaranteed to produce incorrect results in most cases (esp. for small bit-size
>types), I'm +1 on upcasting on this one.
>I agree that in general we shouldn't upcast silently, but I think this is a
>case of 'practicality beats purity'.
Would there be a way of preventing upcasting, if desired?
You wouldn't want to eliminate functionality.
My $0.02: getting bitten is easy, but if I'm doing integer arithmetic,
I usually want to be in control of what exactly is going on. Having the
size of my integer change without my asking for it is ... well, it's not
My feelings on this are significantly influenced by the way I was
"brought up". Might be old fashioned.
BTW, off hand, I can't think of why I personally would want a small
integer, and keep it small even when the number in it gets big. But
maybe cryptographers or somesuch do.
>Think of it this way: almost anyone writing the equivalent to .sum() manually
>in C would write this with a wide enough accumulator, so I think it's OK for
>scipy to do the same.
"wide enough" *to start with*. You wouldn't change it somewhere in
the middle, I don't think.
>Just my 1e-2.
right back at you,
>SciPy-user mailing list
>SciPy-user at scipy.net
More information about the SciPy-user