Opened 9 years ago

Closed 8 years ago

## #15695 closed defect (duplicate)

# Coercion problems between numpy and sage floats

Reported by: | Nils Bruin | 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 9 years ago by

Branch: | → u/nbruin/ticket/15695 |
---|---|

Created: | Jan 19, 2014, 5:28:47 PM → Jan 19, 2014, 5:28:47 PM |

Modified: | Jan 19, 2014, 5:28:47 PM → Jan 19, 2014, 5:28:47 PM |

### comment:2 Changed 9 years ago by

Commit: | → f07008bd6f1e9b5a37a4d3eae874a5eac2815234 |
---|

### comment:3 Changed 9 years ago by

Milestone: | sage-6.1 → sage-6.2 |
---|

### comment:4 Changed 9 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 9 years ago by

Milestone: | sage-6.2 → sage-6.3 |
---|

### comment:6 Changed 8 years ago by

Milestone: | sage-6.3 → sage-6.4 |
---|

### comment:7 Changed 8 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 8 years ago by

Branch: | u/nbruin/ticket/15695 |
---|---|

Commit: | f07008bd6f1e9b5a37a4d3eae874a5eac2815234 |

Milestone: | sage-6.4 → sage-duplicate/invalid/wontfix |

Reviewers: | → Jeroen Demeyer |

Status: | new → needs_review |

### comment:9 Changed 8 years ago by

Status: | needs_review → positive_review |
---|

### comment:10 Changed 8 years ago by

Resolution: | → duplicate |
---|---|

Status: | positive_review → closed |

**Note:**See TracTickets for help on using tickets.

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`