On 7/7/2010 9:43 PM, Charles R Harris wrote:
On Wed, Jul 7, 2010 at 10:13 PM, Christoph Gohlke <cgohlke@uci.edu <mailto:cgohlke@uci.edu>> wrote:
Dear NumPy developers,
I am trying to solve some scipy.sparse TypeError failures reported in [1] and reduced them to the following example:
> >> import numpy > >> a = numpy.array([[1]])
> >> numpy.dot(a.astype('single'), a.astype('longdouble')) array([[1.0]], dtype=float64)
> >> numpy.dot(a.astype('double'), a.astype('longdouble')) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: array cannot be safely cast to required type
Is this exception expected?
I think not. On some platforms longdouble is the same as double, on others it is extended precision or quad precision. On your platform this looks like a bug, on my platform it would be correct except there is a fallback version of dot that works with extended precision. Is there a mix of compilers here, or is it msvc all the way down.
Yes, msvc9 all the way down. It fails no matter whether I build with setup.py or setupscons.py. Using mingw build gives the expected results.
In [5]: a = array([[1]])
In [6]: dot(a.astype('single'), a.astype('longdouble')) Out[6]: array([[1.0]], dtype=float128)
Also I noticed this:
> >> numpy.array([1]).astype('longdouble').dtype.num 13 > >> numpy.array([1.0]).astype('longdouble').dtype.num 12
Yeah, that is probably correct in a strange sort of way since the two types are identical under the hood. On ubuntu I get
In [1]: array([1]).astype('longdouble').dtype.num Out[1]: 13
In [2]: array([1.]).astype('longdouble').dtype.num Out[2]: 13
Type numbers aren't a good way to determine precision in a platform independent way.
I should have mentioned that the following example works for me:
a = numpy.array([[1.0]]) numpy.dot(a.astype('double'), a.astype('longdouble')) array([[ 1.]])
-- Christoph