[SciPy-dev] Question about 64-bit integers being cast to double precision
Fernando.Perez at colorado.edu
Wed Oct 26 13:56:03 CDT 2005
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
> 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
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
Or am I missing some usage case that this would not satisfy?
More information about the Scipy-dev