Opened 8 years ago
Closed 7 years ago
#15695 closed defect (duplicate)
Coercion problems between numpy and sage floats
Reported by: | nbruin | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | coercion | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | Jeroen Demeyer | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
See this 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.
Change History (10)
comment:1 Changed 8 years ago by
- Branch set to u/nbruin/ticket/15695
- Created changed from 01/19/14 17:28:47 to 01/19/14 17:28:47
- Modified changed from 01/19/14 17:28:47 to 01/19/14 17:28:47
comment:2 Changed 8 years ago by
- Commit set to f07008bd6f1e9b5a37a4d3eae874a5eac2815234
comment:3 Changed 8 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:4 Changed 8 years ago by
This might be the right place to deal with #8426 (which now works as requested in that ticket but needs a regression test if that's indeed the behaviour we want to support).
comment:5 Changed 8 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:6 Changed 7 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:7 Changed 7 years ago by
Hello,
I propose to close this as duplicates because of #18076. With the branch applied
sage: import numpy sage: 1j + numpy.float64(2) 2.00000000000000 + 1.00000000000000*I sage: parent(_) Complex Field with 53 bits of precision
But #8824 is still an issue
sage: numpy.float64(2) + 1j (2+1j) sage: parent(_) <type 'numpy.complex128'>
Since as I copied some of the suggestions from the branch, I propose to set you as an author in #18076.
Vincent
comment:8 Changed 7 years ago by
- Branch u/nbruin/ticket/15695 deleted
- Commit f07008bd6f1e9b5a37a4d3eae874a5eac2815234 deleted
- Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
- Reviewers set to Jeroen Demeyer
- Status changed from new to needs_review
comment:9 Changed 7 years ago by
- Status changed from needs_review to positive_review
comment:10 Changed 7 years ago by
- Resolution set to duplicate
- Status changed from positive_review to closed
very basic fix. Feel free to adapt. Don't forget to test (including performance regression. Python should be able to do a
issubtype
really quickly, but it will be slower than an identity test)New commits:
trac #15695: check for subtypes in py_scalar_type