#15695: Coercion problems between numpy and sage floats
------------------------+----------------------------
Reporter: nbruin | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.1
Component: coercion | Keywords:
Merged in: | Authors:
Reviewers: | Report Upstream: N/A
Work issues: | Branch:
Commit: | Dependencies:
Stopgaps: |
------------------------+----------------------------
See this [https://groups.google.com/forum/#!topic/sage-devel/0IalWN4NHig
sage-devel thread].
This problem arises (at least on a lot of machines)
{{{
import numpy as np
sage: isinstance(np.float64(1),float)
True
sage: isinstance(np.float32(1),float)
False
sage: isinstance(np.float128(1),float)
False
sage: isinstance(np.float(1),float)
True
sage: type(np.float(1))
<type 'float'>
sage: parent(np.float64(1))
<type 'numpy.float64'>
}}}
As you can see, numpy decides to map `numpy.float64` a subclass of
`float`. Sage's coercion code wasn't prepared for subclassing. This leads
to awkward coercion problems:
{{{
sage: 1j + np.float64(2)
2.0
}}}
(the result is of type np.float64 rather than CC, i.e., the wrong parent
is chosen).
The simplest choice seems to be to ensure that sage tests for subtypes in
the relevant spot.
--
Ticket URL: <http://trac.sagemath.org/ticket/15695>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
