Sage: Ticket #17713: Towards a genuine RealField
https://trac.sagemath.org/ticket/17713
<p>
<em>One Ring to rule them all.</em>
</p>
<p>
This task ticket aims at discussing and reorganizing the ways to implement an abstraction of the field of real numbers (resp. complex numbers), as well as its interaction with its representations (algebraic, numerical, symbolic, ...).
</p>
<p>
The current approximative representations of real numbers (see also <a class="new ticket" href="https://trac.sagemath.org/ticket/15944" title="enhancement: Thematic tutorial about real and complex numbers in Sage (new)">#15944</a>) are
</p>
<ul><li><code>RealDoubleField()</code> (<code>RDF</code>) using <code>double</code> / <code>ComplexDoubleField()</code> (<code>CDF</code>)
</li><li><code>RealField(prec)</code> (<code>RR</code>) using <code>mpfr_t</code> / <code>ComplexField(prec)</code> (<code>CC</code>)
</li><li><code>MPComplexField(prec)</code> using <code>mpc_t</code>
</li><li><code>RealIntervalField(prec)</code> (<code>RIF</code>) using <code>mpfi_t</code> / <code>ComplexIntervalField(prec)</code> (<code>CIF</code>)
</li><li><code>RealBallField(prec)</code> (<code>RBF</code>) using <code>arb_t</code> / <code>ComplexBallField(prec)</code> (<code>CBF</code>) using <code>acb_t</code>
</li></ul><p>
And the exact or symbolic ones
</p>
<ul><li><code>RationalField()</code> (<code>QQ</code>) using <code>mpq_t</code>
</li><li><code>AlgebraicRealField()</code> (<code>AA</code>) / <code>AlgebraicField()</code> (<code>QQbar</code>)
</li><li><code>NumberField(poly)</code> and <code>QuadraticField(n)</code>
</li><li><code>SymbolicRing()</code> (<code>SR</code>) - mostly unreliable concering comparison, equality, etc
</li></ul><p>
See also the discussion in <a class="closed ticket" href="https://trac.sagemath.org/ticket/14567" title="enhancement: Refactor continued fractions (closed: fixed)">#14567</a>.
</p>
<hr />
<h2 id="Concretetickets">Concrete tickets</h2>
<h3 id="Cleaningrealcomplexfloating-point">Cleaning real/complex floating-point</h3>
<ul><li><a class="needs_work ticket" href="https://trac.sagemath.org/ticket/24483" title="enhancement: complex_field.py complex_number.pyx -> complex_mpfr.pyx (needs_work)">#24483</a>: complex numbers step 1
</li><li><a class="new ticket" href="https://trac.sagemath.org/ticket/24489" title="task: modernize complex_mpfr (new)">#24489</a>: complex numbers step 2
</li><li><a class="needs_work ticket" href="https://trac.sagemath.org/ticket/24457" title="task: modernize sage.rings.real_mpfr (needs_work)">#24457</a>: real numbers
</li></ul><h3 id="Documentationtutorials">Documentation, tutorials</h3>
<ul><li><a class="new ticket" href="https://trac.sagemath.org/ticket/15944" title="enhancement: Thematic tutorial about real and complex numbers in Sage (new)">#15944</a>: real number and computers
</li></ul><h3 id="Creationofabstractclasses">Creation of abstract classes</h3>
<ul><li><a class="needs_work ticket" href="https://trac.sagemath.org/ticket/24456" title="enhancement: classes for the fields of complex and real numbers (needs_work)">#24456</a>: <code>sage.rings.real_field.RealField</code> and <code>sage.rings.complex_field.ComplexField</code>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/17713
Trac 1.1.6mmezzarobbaTue, 10 Feb 2015 08:38:36 GMT
https://trac.sagemath.org/ticket/17713#comment:1
https://trac.sagemath.org/ticket/17713#comment:1
<p>
Thierry, could you elaborate on what you have in mind? It is not clear to me from the comments on the other ticket.
</p>
TicketrwsTue, 17 Feb 2015 13:47:42 GMTmilestone changed
https://trac.sagemath.org/ticket/17713#comment:2
https://trac.sagemath.org/ticket/17713#comment:2
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.5</em> to <em>sage-wishlist</em>
</li>
</ul>
TickettmonteilThu, 26 Mar 2015 01:59:25 GMT
https://trac.sagemath.org/ticket/17713#comment:3
https://trac.sagemath.org/ticket/17713#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/17713#comment:1" title="Comment 1">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Thierry, could you elaborate on what you have in mind? It is not clear to me from the comments on the other ticket.
</p>
</blockquote>
<p>
I had more to review on <a class="closed ticket" href="https://trac.sagemath.org/ticket/14567" title="enhancement: Refactor continued fractions (closed: fixed)">#14567</a> but it had to be merged at some point (my previous review was already big).
</p>
<p>
What i have in mind about the quoted sentence is related to what was discussed at
<a class="ext-link" href="https://groups.google.com/forum/#!msg/sage-devel/0vAo1AnPVOU/ZAg2U2dKeioJ"><span class="icon"></span>https://groups.google.com/forum/#!msg/sage-devel/0vAo1AnPVOU/ZAg2U2dKeioJ</a>
<a class="ext-link" href="http://thread.gmane.org/gmane.comp.mathematics.sage.devel/70858"><span class="icon"></span>http://thread.gmane.org/gmane.comp.mathematics.sage.devel/70858</a>
</p>
<p>
More precisely (this is only an early draft):
</p>
<ul><li>Deprecate <code>CFF</code> (Continued Fraction Field) because it is only a
representation overlay over <code>QQ</code> (all computations are done in <code>QQ</code>,
only the representation changes), so i am in favor to either remove
<code>CFF</code> since <code>QQ</code> has now a <code>.continued_fraction()</code> method which does the
same job, or add a <code>.repr_as_cf</code> flag in <code>QQ</code> to change the
representation of rationals and see them as (finite) continued fractions
(this can be useful if we want to see continued fractions along a
computation involving rationals, so that we do not have to call the
<code>.continued_fraction()</code> each time).
</li></ul><ul><li>Put <code>RR</code> at the same naming level than the other approximations of the
real field (<code>RDF</code>, <code>RIF</code>, <code>RBF</code> (<a class="closed ticket" href="https://trac.sagemath.org/ticket/17194" title="enhancement: Minimal bindings for optional arb package (closed: fixed)">#17194</a>), <code>RLF</code>,...), i.e. rename it
<code>RFF</code> ("Real Floating Field"). Currently, claiming that this is the
right default approximation causes a lot of misunderstandings (both on
the user and the devel side). An improved version of this item could be
to even replace the word "Field" by "Numbers" (<code>RDN</code>, <code>RIN</code>, <code>RBN</code>,
<code>RLN</code>, <code>RFN</code>, ...) or "Approximation" (<code>RDA</code>, <code>RIA</code>, <code>RBA</code>, <code>RLA</code>,
<code>RFA</code>, ...).
</li></ul><ul><li>Create a <code>RSF</code> ("Real Symbolic Field") of symbolic expressions
representing real numbers. Indeed, those are currently part of <code>SR</code>
which is an attracting dead end for coercion, so that currently <code>pi+0.1</code>
is symbolic while it should be numeric (loss of precision). An advantage
is that <code>RSF</code> will be as high as <code>AA</code> in the coercion hierarchy and
<code>RSF</code> will be an exact field. So:
<pre class="wiki">pi + log(2) in RSF
pi + log(2) + 0.1 in RFF
pi + log(2) + 0.1 + cos(x) in SR (dead end)
</pre></li></ul><ul><li>Now, since the name <code>RR</code> is freed, we can let it represent the genuine
real field, as <code>NN</code>, <code>ZZ</code>, <code>QQ</code>, <code>AA</code> correspond to genuine rings (not
approximations), the new <code>RR</code> can be temporarly named <code>GRR</code> for
deprecation time if needed ("Genuine Real Field"). So, we will have an
object to serve as an abstraction of the field of real numbers, in
particular, it could host methods for telling whether an element is a
real number, whether a parent is an approximation of the real field
(<code>RDF</code>, <code>RIF</code>, <code>RLF</code>,...). There will be a semantic difference with the
<code>R*F</code> approximations, for example on could make the distinction between
<code>.is_field()</code> and `.is_approximate_field() (+ update category framework
accordingly), <code>RR</code> is a field, <code>RDF</code> is almost a field, so that we both
have the mathematical information, and the computational one (you have
the right to use this faster algorithm because you can divide)).
</li></ul><p>
But this abstract field could also work as an overlay over the existing representations, and therefore be the parent of some elements.
</p>
<p>
The name "overlay" could be understood as follows (this preliminary proposal should of course be collectively improved): by default, an element of <code>RR</code> (the genuine real field) is stored as the set of the maximal elements (for the coercion) of its available representatives.
</p>
<p>
For example:
</p>
<ul><li><code>a = sqrt(2) + sqrt(3)</code> is stored as its representations in both <code>AA</code>
and <code>RSF</code>.
</li><li><code>a + log(2)</code> is stored as its representation in <code>RSF</code>.
</li><li>if <code>b</code> is an algebraic number of high degree which does not admit a
representation by radicals, then <code>a + b</code> is stored as its
representaion in <code>AA</code>.
</li><li><code>a + b + log(2)</code> is stored as its representaion in RLF.
</li><li><code>a + b + log(2) + RR(RIF(0.1))</code> is stored as its representaion in
<code>RIF</code>.
</li><li><code>a + RR(RDF(0.1))</code> is stored as its representaion in <code>RDF</code>.
</li></ul><p>
A coercion between <code>RR</code> and a particular representation falls into some representation (<code>RR</code> is not absorbing (while <code>SR</code> is)):
</p>
<ul><li><code>a + RIF(2)</code> belongs to <code>RIF</code>
</li><li><code>log(RR(2)) + AA(2)</code> belongs to <code>RR</code>
</li></ul><p>
So, in the coercion DAG, <code>RR</code> is below <code>QQ</code> and <code>AA</code>, but above all the <code>R*F</code>.
</p>
<p>
Along a computation, the set of representatives can grow, for example, if we do some numerical computations involving a, a can also cache some of its numerical reprentations to ease further computations.
</p>
<p>
A possibility could be to have a <code>._tight</code> flag in <code>RR</code> to use more information than the raw coercion described above. For example, the coercion between <code>AA</code> and <code>RIF</code> falls into <code>RIF</code>, but one could ask <code>RR</code> to consider that <code>RR(sqrt(2)) + RR(RIF(2))</code> keeps a representative in <code>AA</code> since both endpoints of <code>RIF(2)</code> are equal (so we are guaranteed that this is the integer 2). In <code>R*F</code>, this does not make sense since we want the coercion to work independently of the elements (it is decided at the parent level), but within <code>RR</code>, we could want to lose as few information as possible (why not, we are within a single parent). Also, with <code>_tight</code> flag on, <code>a = RR(pi/5)</code> is represented as <code>RSF</code>, but <code>cos(a)</code> is represented as <code>RSF</code> and <code>AA</code>. I guess the default should be the one provided by coercion of representatives (less powerful, but faster and easier to predict).
</p>
<p>
<code>RR</code> could have a <code>._repr</code> flag, where we could have symbolic representation, scientific notation, continued fractions,... the <code>.__repr__()</code> method of RR elements could use colors to indicate how exact/secure is its current representation (there is a difference between <code>RR(sqrt(2))</code> (exact), <code>RR(RIF(0.1))</code> (inexact but secure) and <code>RR(RDF(0.1)))</code> (inexact and insecure).
</p>
<p>
Of course, all this should be extended to complex numbers as well (though we will encounter problems with <code>CSF</code> since <code>SR</code> currently lacks semantics about ramifications (e.g. cube roots or logs) while we have to ensure reliability with that respect since <code>CSF</code> is pretty high in the coercion hierarchy).
</p>
<p>
As positive effects:
</p>
<ul><li>Necommers will stop using <code>RFF</code> (currently named <code>RR</code>) by default,
while it is both inexact and much slower than <code>RDF</code>. They will
understand the difference between a real number and its possible
representatives (symbolic, algebraic, numeric).
</li></ul><ul><li>There will not be meaningless discussions on sage-devel on whether
<code>NaN</code> or <code>Infinity</code> should belong to <code>RFF</code> (no one complained for
<code>RDF</code>, the problem comes from the fact that people expect the current
<code>RR</code> to be the genuine real field, while it is only one of its
approximation).
</li></ul><ul><li>This will host all methods related to the mathematical notion of real
numbers, independently of its reprentation, for example:
<ul><li>given a Sage object, you can ask whether it is real by typing:
<pre class="wiki">sage: 0.2 in RR
True
sage: pi in RR
True
sage: infinity in RR
False
sage: NaN in RR
False
</pre></li><li>we make the distinction between mathematical aspect and
computational one:
<pre class="wiki">sage: RR.is_field()
True
sage: RDF.is_field()
False
sage: RDF.is_field_approximation()
True
sage: %timeit det(random_matrix(RDF,100))
2 ns (i used the fast algorithm because i could divide)
sage: RR.cardinality()
+Infinity # or 2^aleph_0 if defined
sage: RDF.cardinality()
18446744073709551615 # or some correct number
</pre></li><li>this is a good place to host the method answering "Checking
whether a Parent models the real field", see :
<a class="ext-link" href="https://groups.google.com/forum/#!topic/sage-devel/m822J7mYA0Q"><span class="icon"></span>https://groups.google.com/forum/#!topic/sage-devel/m822J7mYA0Q</a>
<a class="ext-link" href="http://thread.gmane.org/gmane.comp.mathematics.sage.devel/76733"><span class="icon"></span>http://thread.gmane.org/gmane.comp.mathematics.sage.devel/76733</a>
<pre class="wiki">sage: RR.is_modeled_by(RLF)
True
sage: RR.is_modeled_by(CDF)
False
sagel RR.is_modeled_by(GF(2))
False
</pre></li><li>perhaps <code>RR</code> could ease the preparsing issue about user inputs
that are context dependent such as <code>'0.1'</code> or <code>'1e-20'</code> to defer
the choice of a representation until it is coerced as discussed on
sage-devel (i have no opinion on that subject though, since i do
not use real litterals much).
</li></ul></li></ul><blockquote>
<blockquote>
<blockquote>
<p>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.mathematics.sage.devel/101/match=real+literals"><span class="icon"></span>http://article.gmane.org/gmane.comp.mathematics.sage.devel/101/match=real+literals</a>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.mathematics.sage.devel/3427/match=real+literals"><span class="icon"></span>http://article.gmane.org/gmane.comp.mathematics.sage.devel/3427/match=real+literals</a>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.mathematics.sage.devel/12326/match=real+literals"><span class="icon"></span>http://article.gmane.org/gmane.comp.mathematics.sage.devel/12326/match=real+literals</a>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.mathematics.sage.devel/13839/match=real+literals"><span class="icon"></span>http://article.gmane.org/gmane.comp.mathematics.sage.devel/13839/match=real+literals</a>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.mathematics.sage.devel/16578/match=real+literals"><span class="icon"></span>http://article.gmane.org/gmane.comp.mathematics.sage.devel/16578/match=real+literals</a>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.mathematics.sage.devel/62514/match=real+literals"><span class="icon"></span>http://article.gmane.org/gmane.comp.mathematics.sage.devel/62514/match=real+literals</a>
<a class="ext-link" href="http://thread.gmane.org/gmane.comp.mathematics.sage.devel/69699/match=real+literals"><span class="icon"></span>http://thread.gmane.org/gmane.comp.mathematics.sage.devel/69699/match=real+literals</a>
</p>
<pre class="wiki">sage: 0.1 + 1/3
13/30
sage: 0.1 + RDF(0.1)
0.200000000000000
sage: 0.1 + RealFloatingField(1000)(0.1)
0.200000000000000000000000000000000000000000...
</pre></blockquote>
</blockquote>
</blockquote>
<p>
For dealing with infinities, we could add (mathematical) one-point (resp two-points) compactification <code>RRhat</code> (resp. <code>RRbar</code>), <code>CChat</code> (Riemann sphere), which have more mathematical meaning than the <code>InfinityRing</code>, that currently behaves as follows:
</p>
<pre class="wiki">sage: 2 in InfinityRing
True
sage: pi in InfinityRing
False
sage: InfinityRing(NaN) == InfinityRing(-1)
True
</pre><p>
While we are at it, i would like to work on a well defined conversion from <code>AA</code> to <code>RSF</code> using Galois theory, which seems to be on the road now, see <a class="new ticket" href="https://trac.sagemath.org/ticket/17516" title="enhancement: Radical expressions for roots of polynomials using Galois theory (new)">#17516</a>.
</p>
<p>
Once all this is done, we could imagine to also create a <code>RCF</code> ("Real Constructive Field") of numbers that can be approximated with a Turing machine to arbitrary good precision (it would be created by an iterator or a function that, given a precision returns a rational within the interval).
</p>
<p>
Remark: note that under the hood, <code>RLF</code> seems to also have a kind of overlay mechanism, but it is not very handy, nor transparent to the user, nor mathematically meaningful. Also, it is not able to store more than one representative, while <code>RSF</code> and <code>AA</code> are not comparable in the hierarchy of coercion.
</p>
<pre class="wiki">sage: a = RLF(pi+cos(2))
sage: b = RLF(AA(sqrt(2)))
sage: a._value.parent()
Symbolic Ring
sage: b._value.parent()
Algebraic Real Field
sage: c = a+b
sage: c._value
AttributeError
sage: c._op
<built-in function add>
sage: a._op
AttributeError
sage: r = RLF(2)
sage: s = r.sqrt()
sage: s._value
AttributeError
sage: s._op
'sqrt'
</pre>
TicketmmezzarobbaThu, 09 Apr 2015 07:59:56 GMT
https://trac.sagemath.org/ticket/17713#comment:4
https://trac.sagemath.org/ticket/17713#comment:4
<p>
Thanks for your explanations! Just some quick comments and questions (I don't think I will have time to think about all that in detail soon).
</p>
<ul><li>I still don't really understand the difference you are envisioninig between <code>RLF</code> and your <code>GRR</code>. Why not just improve <code>RLF</code>? Also, what would be the benefits of storing multiple representatives of a real number? Same question with <code>RCF</code>.
</li><li>I also don't see what this all has to do with continued fractions.
</li><li>As far as I understand the intention of <code>SR</code> (well, not <em>all</em> of <code>SR</code>, but things like elementary and special functions, limits, etc.) is to sort-of-model complex variable calculus, and the problems with branch cuts of analytic functions are bugs.
</li><li>There seems to be a weak consensus that an algebraic structure name ”Foo“ in Sage (esp. in parent and category names) means ”Effective Foo”. None of your real fields (even the exact ones) are ”Fields“ in this sense, since the zero test is undecidable.
</li><li>Regarding names, I think I like <code>FPR</code> (or <code>RFP</code>) for floating-point numbers and <code>IR</code> for intervals better than what you suggest.
</li><li>Using <code>in RR</code> to test if something ”is real“ still wouldn't be a good idea in many cases, since there certainly would still be parents with some ”real“ elements that wouldn't coerce into <code>RR</code>.
</li><li>The problem with <code>InfinityRing(NaN)</code> could simply be solved by adding a <code>NaN</code> element to <code>InfinityRing</code>. This makes sense with the current model. Defining a compactification mechanism may also be a good idea, but then I guess compactifications should be generic constructions that take any suitable parent and extend it with one or two points at infinity. In other words, I doubt we need an <code>RRbar</code>, just a <code>TwoPointCompactification(RR)</code> and a corresponding functor that the coercion system could apply to decide that the universe of <code>[RR(1), -infinity]</code> is <code>TwoPointCompactification(RR)</code>.
</li></ul>
TicketsstarostaMon, 20 Jul 2015 08:22:23 GMTcc changed
https://trac.sagemath.org/ticket/17713#comment:5
https://trac.sagemath.org/ticket/17713#comment:5
<ul>
<li><strong>cc</strong>
<em>sstarosta</em> added
</li>
</ul>
TickettmonteilThu, 10 Mar 2016 16:23:47 GMT
https://trac.sagemath.org/ticket/17713#comment:6
https://trac.sagemath.org/ticket/17713#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/17713#comment:4" title="Comment 4">mmezzarobba</a>:
</p>
<blockquote class="citation">
<ul><li>I still don't really understand the difference you are envisioninig between <code>RLF</code> and your <code>GRR</code>. Why not just improve <code>RLF</code>?
</li></ul></blockquote>
<p>
Mainly because there are some non-lazy representations of real numbers. Here "lazy" is related to a representation of real numbers as iterators, and the current implementation deals about that facet, i do not see the point in thinking of the real number <code>1/3</code> as <code>0.3333333...</code> by default. I have nothing against improving <code>RLF</code> though, but i think we have to give a separate name to an abstraction of the genuine real field as a mathematical object (that could also carry some categorial information, the fact that is indeed a field, and so on), if only to make the notion of representation clear.
</p>
<blockquote class="citation">
<p>
Also, what would be the benefits of storing multiple representatives of a real number?
</p>
</blockquote>
<p>
I am not sure about this point, this is only a proposal! Somehow, the existing repesentations of real numbers do not form a linear order for the coercion, so when a real number can be reresented in two such representations, there is a loss to choose one of them or to use the common parent. Probably only practice would decide whether this is a good idea, this should be experimented.
</p>
<blockquote class="citation">
<p>
Same question with <code>RCF</code>.
</p>
</blockquote>
<p>
The field of effective numbers is well defined, i am not specialist, but there are both some theoretical results about this and even some implementations, so, if someone feel to put this in Sage, i do not see the problem. Actually, i write say <code>RRF</code> for "real recursive field".
</p>
<blockquote class="citation">
<ul><li>I also don't see what this all has to do with continued fractions.
</li></ul></blockquote>
<p>
As for me, nothing. I did not chose the title of this ticket, but i guess this is because some discussion happen in a continued fraction ticket.
</p>
<blockquote class="citation">
<ul><li>As far as I understand the intention of <code>SR</code> (well, not <em>all</em> of <code>SR</code>, but things like elementary and special functions, limits, etc.) is to sort-of-model complex variable calculus, and the problems with branch cuts of analytic functions are bugs.
</li></ul></blockquote>
<p>
Indeed! Unfortunately numbers like <code>sqrt(pi)</code> belong to this big object, and are interesting as real numbers. The idea is to extract such variable-free expressions to a smaller class of "real symbolic numbers" (with trivial inclusion in both <code>GRR</code> and <code>SR</code>).
</p>
<p>
Condidering branch problems as bugs (i agree!) does not provide an estimate on the time to fix them, especially since we rely on external libraries for this.
</p>
<blockquote class="citation">
<ul><li>There seems to be a weak consensus that an algebraic structure name ”Foo“ in Sage (esp. in parent and category names) means ”Effective Foo”. None of your real fields (even the exact ones) are ”Fields“ in this sense, since the zero test is undecidable.
</li></ul></blockquote>
<p>
Indeed. I agree that such property should be made explicit in each representation (similar to <code>is_exact</code>). However, as long as some not effective (in your sense) representations are useful, i do not see the point not to consider them.
</p>
<blockquote class="citation">
<ul><li>Regarding names, I think I like <code>FPR</code> (or <code>RFP</code>) for floating-point numbers and <code>IR</code> for intervals better than what you suggest.
</li></ul></blockquote>
<p>
I agree with that (i wrote "An improved version of this item could be to even replace the word "Field" by "Numbers" (<code>RDN</code>, <code>RIN</code>, <code>RBN</code>, <code>RLN</code>, <code>RFN</code>, ...) or "Approximation" (<code>RDA</code>, <code>RIA</code>, <code>RBA</code>, <code>RLA</code>, <code>RFA</code>, ...)."). Changing only <code>RR</code> to <code>RFF</code> was a less disruptive proposal, i am not sure until which point we can reach a consensus (i am not even convinced that there will eventually be a consensus to rename <code>RR</code> to be consistent with its actual nature).
</p>
<blockquote class="citation">
<ul><li>Using <code>in RR</code> to test if something ”is real“ still wouldn't be a good idea in many cases, since there certainly would still be parents with some ”real“ elements that wouldn't coerce into <code>RR</code>.
</li></ul></blockquote>
<p>
This is one reason to isolate <code>RSF</code> from <code>SR</code>, because the coercion order will be RSF > RR > SR.
</p>
<blockquote class="citation">
<ul><li>The problem with <code>InfinityRing(NaN)</code> could simply be solved by adding a <code>NaN</code> element to <code>InfinityRing</code>. This makes sense with the current model. Defining a compactification mechanism may also be a good idea, but then I guess compactifications should be generic constructions that take any suitable parent and extend it with one or two points at infinity.
</li></ul></blockquote>
<p>
Yes.
</p>
<blockquote class="citation">
<p>
In other words, I doubt we need an <code>RRbar</code>, just a <code>TwoPointCompactification(RR)</code> and a corresponding functor that the coercion system could apply to decide that the universe of <code>[RR(1), -infinity]</code> is <code>TwoPointCompactification(RR)</code>.
</p>
</blockquote>
<p>
Well, this is nothing but a shortcut, as well as <code>RDF</code> is a shortcut of <code>RealDoubleField()</code>. I have no strong opinion on whether it should be included into the namespace.
</p>
TickettmonteilFri, 05 Jan 2018 01:00:26 GMTtype, description, summary changed
https://trac.sagemath.org/ticket/17713#comment:7
https://trac.sagemath.org/ticket/17713#comment:7
<ul>
<li><strong>type</strong>
changed from <em>enhancement</em> to <em>task</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/17713?action=diff&version=7">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>implement GoodRealField with help of continued fractions</em> to <em>Towards a genuine RealField</em>
</li>
</ul>
TickettmonteilFri, 05 Jan 2018 01:20:15 GMTcc changed
https://trac.sagemath.org/ticket/17713#comment:8
https://trac.sagemath.org/ticket/17713#comment:8
<ul>
<li><strong>cc</strong>
<em>tscrim</em> <em>vdelecroix</em> <em>jdemeyer</em> <em>egourgoulhon</em> added
</li>
</ul>
TickettmonteilFri, 05 Jan 2018 02:50:49 GMTdescription changed
https://trac.sagemath.org/ticket/17713#comment:9
https://trac.sagemath.org/ticket/17713#comment:9
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/17713?action=diff&version=9">diff</a>)
</li>
</ul>
TicketvdelecroixMon, 08 Jan 2018 09:11:06 GMTdescription changed
https://trac.sagemath.org/ticket/17713#comment:10
https://trac.sagemath.org/ticket/17713#comment:10
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/17713?action=diff&version=10">diff</a>)
</li>
</ul>
TicketvdelecroixWed, 10 Jan 2018 09:59:48 GMTdescription changed
https://trac.sagemath.org/ticket/17713#comment:11
https://trac.sagemath.org/ticket/17713#comment:11
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/17713?action=diff&version=11">diff</a>)
</li>
</ul>
Ticket