[SciPy-dev] PyArray_CanCastSafely(exact,inexact) on 64-bit

[Travis Oliphant]

Pearu Peterson wrote:

>Hi Travis,
>
>Number of scipy.test failures occuring on 64-bit systems are due to the 
>fact that PyArray_CanCastSafely(PyArray_LONG,PyArray_DOUBLE) returns true.
>
>  
>
We had this discussion about a week ago, so you should definitely look 
at other comments from that discussion.  What exactly are you trying to 
do that is causing the errors?

>Though sizeof(long)==sizeof(double) holds on 64-bit machines, shouldn't 
>PyArray_CanCastSafely return false on (exact,inexact) arguments and vice 
>versa?
>  
>
It's never done that in the past, so this would represent quite a 
switch.   It has always been possible to convert from integers to floats 
"safely."  On old Numeric you could cast from int8 and int16 to float32 
"safely" and from int32 to float64 "safely". 

The problem is with 64-bit integers.  They can't be represented by 
64-bit floats, and the original code only allowed them to be converted 
safely to long double floats.  But, because on 64-bit platforms, the 
long is often 64-bits and that's the default Python integer, it would 
mean always doing long double calculations.

PyArray_CanCastSafely is used largely for determining the "coercion" 
rules for ufuncs.  The current function causes sqrt(2) to take place 
with double precision.

>By the definition of can_cast, no bitwise information is lost, but
>it is not meaningful to pass (double*)(<pointer to long array>) to a 
>numeric function, for example.
>  
>
But, that's never been what CanCastSafely has been used to represent.  
Perhaps we need a different function that distinguishes between 
different kinds.  Again, what are you trying to do, specifically?

>Or may be I should use some different function than PyArray_CanCastSafely 
>in this situation?
>  
>
I suspect so...

-Travis