[SciPy-dev] PyArray_CanCastSafely(exact,inexact) on 64-bit
oliphant at ee.byu.edu
Sun Oct 30 19:40:15 CST 2005
Pearu Peterson wrote:
>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
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...
More information about the Scipy-dev