Opened 3 years ago
Last modified 3 months ago
#25458 new defect
Inconsistent printing of algebraic numbers
Reported by: | rws | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-9.4 |
Component: | number fields | Keywords: | |
Cc: | slelievre | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
sage: QQbar(2*I)^(1/2) 1 + 1*I sage: type(_) <class 'sage.rings.qqbar.AlgebraicNumber'> sage: QQbar(I)+1 I + 1 sage: type(_) <class 'sage.rings.qqbar.AlgebraicNumber'>
Change History (8)
comment:1 follow-up: ↓ 2 Changed 3 years ago by
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 3 years ago by
Replying to slabbe:
Notice that:
sage: AA.options.display_format = 'radical'recently introduced (#25210) fixes the problem:
It is not a fix if you have to set it every time to get a consistent result. The fix would be to make it the default from the start. Until that ticket the output was consistent, so #25210 actually introduced a bug.
comment:3 in reply to: ↑ 2 Changed 3 years ago by
Replying to rws:
It is not a fix if you have to set it every time to get a consistent result.
It was not intended to be a fix, just a side note.
The fix would be to make it the default from the start.
This is one possibility. Maybe there is a another possibility that would fix the default display format without using the radical display format.
Until that ticket the output was consistent, so #25210 actually introduced a bug.
To my knowledge (I reviewed #25210), the default behavior was not affected by #25210. Moreover, on 8.0 and on sagecell currently running 8.2, I am able to reproduce the inconsistency. Therefore, it seems on the contrary that the bug was present *before* #25210:
┌────────────────────────────────────────────────────────────────────┐ │ SageMath version 8.0, Release Date: 2017-07-21 │ │ Type "notebook()" for the browser-based notebook interface. │ │ Type "help()" for help. │ └────────────────────────────────────────────────────────────────────┘ sage: QQbar(2*I)^(1/2) 1 + 1*I sage: QQbar(I)+1 I + 1
comment:4 Changed 3 years ago by
So do you have any idea to fix the print inconsistency?
Making
sage: AA.options.display_format = 'radical'
the default is a solution, but maybe it should be discussed on sage-devel first?
comment:5 Changed 17 months ago by
The elements print differently depending on how they are represented internally (see AlgebraicNumber_base._repr_
).
- This element is represented exactly as an element of
QuadraticField(-1)
:sage: QQbar(1 + I) I + 1
- This element is represented implicitly as a root of a polynomial, so the
CIF
approximation is used for printing:sage: QQbar(2*I)^(1/2) 1 + 1*I
- If the display format is
radical
, the representation as a radical symbolic expression inSR
is printed instead:sage: (QQbar(2*I)^(1/2)).radical_expression() I + 1
(This is rather inefficient in general, so should not become the default.)
It is difficult to unify these three cases. It would not be too hard to change the order of real and imaginary part in (1) to appear the same as (2), but then (3) would look different. The radical expressions in SR
in (3) are not in general written in terms of real and imaginary part, so this cannot easily be changed to look like (2); for example:
sage: QQbar(sqrt(2) + I).radical_expression() sqrt(2*I*sqrt(2) + 1)
On the other hand, making (2) look the same as (1) is also not trivial, as it would require special cases if the imaginary part is exactly 1 or -1, and even then, there are more differences between the representations, for example:
sage: QQbar(1 + I) * 2^60 1152921504606846976*I + 1152921504606846976 sage: QQbar(2*I)^(1/2) * 2^60 1.1529215046068470?e18 + 1.1529215046068470?e18*I
comment:6 Changed 13 months ago by
- Cc slelievre added
- Component changed from numerical to number fields
- Milestone changed from sage-8.3 to sage-9.2
comment:7 Changed 9 months ago by
- Milestone changed from sage-9.2 to sage-9.3
comment:8 Changed 3 months ago by
- Milestone changed from sage-9.3 to sage-9.4
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
Notice that:
recently introduced (#25210) fixes the problem: