[SciPy-dev] Question about 64-bit integers being cast to double precision

[Fernando Perez]

Charles R Harris wrote:

> Yes, I agree with this. The only problem I see is if someone wants to save
> space when taking the sqrt of an integral array. There are at least three
> possiblilities:
> 
> 1. cast the result to a float
> 2. cast the argument to a float
> 3. use a special sqrtf function
> 
> The first two options use more temporary space, take more time, and look
> uglier (IMHO). On the other hand, the needed commands are already
> implemented. The last option is clear and concise, but needs a new ufunc.

Well, while I agree with the recently posted design guideline from Guido of 
using different functions for different purposes rather than flags, this may 
be a case where a flag would be a good choice.  Especially because we already 
have a conceptual precedent for the accumulators of specifying the return type 
via a flag: a.sum(rtype=int).

Since the 'mental slot' is already in scipy's users heads for saying 'modify 
the default output of this function to accumulate/store data in a different 
type', I think it would be reasonable to offer

sqrt(a,rtype=float)

as an optional way to prevent automatic upcasting in cases where users want 
that kind of very fine level control.  This can be done uniformly across the 
library, rather than growing a zillion foof/food/foo* post-fixed forms of 
every ufunc in the library.

We would then have:

- A basic principle for how upcasting is done, driven by the idea of 
'protecting precision even at the cost of storage'.  This principle forces 
sqrt(2) to be a double and anint_array.sum() to accumulate to a wider type.

- A uniform mechanism for overriding upcasting across the library, via the 
rtype flag.  If most/all of scipy implements this, it seems like a small price 
of learning to pay for a reasonable balance between convenience, correctness 
and efficiency.

Or am I missing some usage case that this would not satisfy?

Cheers,

f