Gary Pajer wrote:
>>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.
>>The only thing that would change is what the default reduce type is.
You can already get the desired behavior by specifying a wider reduce
type explicitly.
One issue, though. Upcasting to a different type will be slower.
Right now the defaults is that the reduce type is the same as the type
of the object coming in. We could change this to some "wide" type.
But should we? It will carry a speed hit. But the user can always
over-ride the default behavior by an explicit rtype= paramter.
I'd like more opinions...
-Travis