[SciPy-user] operations on int8 arrays

Gary Pajer gpajer at rider.edu
Wed Oct 19 17:13:10 EDT 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 
>>think?
>>    
>>
>
>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 
control.
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.
>
>Cheers,
>
>f
>  
>
right back at you,
-g

>_______________________________________________
>SciPy-user mailing list
>SciPy-user at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-user
>
>  
>




More information about the SciPy-User mailing list