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

[Fernando Perez]

Charles R Harris wrote:

[...]

> Now, python does the following:
> 
> 
>>>>from math import *
>>>>sqrt(2)
> 
> 1.4142135623730951
> 
> and if we are going to overload sqrt we should keep this precision. Do
> we really want to make a distinction in this case between math.sqrt and
> Numeric.sqrt ? I myself don't think so. On the other hand, it is
> reasonable that scipy not promote float types in this situation.
> Integral types remain a problem. What about uint8 vs uint64 for
> instance?

Again, I find it simplest to think about this problem in terms of 
exact/approximate numbers.  All integer types (of any bit-width) are exact, 
all float numbers are approximate.  The question is then how to handle 
functions, which can be (in terms of their domain/range relation):

1. f : exact -> exact
2. f : exact -> approximate

etc.

My argument is that for #2, there should be upcasting to the widest possible 
approximate type, in an attempt to preserve as much of the original 
information as we can.  For example, sqrt(2) should upcast to double, because 
truncation to integer makes very little practical sense.

The case of accumulators is special, because they are of type 1 above, but the 
result may not (and often doesn't) fit in the input type.  Travis already 
agreed that in this case, an upcast was a reasonable compromise.

However, for functions of the kind

3. f : approx -> approx

there should be in general no upcasting (except for accumulators, as we've 
discussed).  Doing a*b to two float arrays should certainly not produce an 
enormous result, which may not even fit in memory.

Just my opinion.

Cheers,

f