Sage: Ticket #24219: critical bug in comparison between RealField and QQ
https://trac.sagemath.org/ticket/24219
<pre class="wiki">sage: RealField(2)(1) >= 5/4
True
</pre><p>
This is clearly wrong.
</p>
<p>
The reason is that <code>5/4</code> is first converted to a 2-bit
floating-point number, which is <code>1</code> in mode to nearest, then the comparison is made.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/24219
Trac 1.2Frédéric ChapotonWed, 15 Nov 2017 14:37:22 GMT
https://trac.sagemath.org/ticket/24219#comment:1
https://trac.sagemath.org/ticket/24219#comment:1
<pre class="wiki">sage: t
1.0
sage: RealField(2)(5/4)
1.0
</pre><p>
So this is not really a bug
</p>
TicketPaul ZimmermannWed, 15 Nov 2017 15:00:02 GMT
https://trac.sagemath.org/ticket/24219#comment:2
https://trac.sagemath.org/ticket/24219#comment:2
<p>
I did not ask <code>t >= RealField(2)(5/4)</code>, but <code>t >= 5/4</code>.
Does the following convince you? Note that 6*t is exactly representable in 2-bit precision.
</p>
<pre class="wiki">sage: t = RealField(2)(1)
sage: t >= 7/6
True
sage: 6*t >= 7
False
</pre>
TicketFrédéric ChapotonWed, 15 Nov 2017 15:04:14 GMT
https://trac.sagemath.org/ticket/24219#comment:3
https://trac.sagemath.org/ticket/24219#comment:3
<p>
Well, comparison happens after coercion, and coercion can only lose precision. If you want comparison that makes sense, you should avoid using such a small precision.
</p>
TicketPaul ZimmermannWed, 15 Nov 2017 15:19:41 GMT
https://trac.sagemath.org/ticket/24219#comment:4
https://trac.sagemath.org/ticket/24219#comment:4
<p>
where is it documented that comparison happens after coercion? Is the user warned about that?
And why is the coercion done in the direction QQ to <a class="missing wiki">RealField?</a> and not the converse, which would not lose any information?
</p>
TicketFrédéric ChapotonWed, 15 Nov 2017 15:22:08 GMT
https://trac.sagemath.org/ticket/24219#comment:5
https://trac.sagemath.org/ticket/24219#comment:5
<p>
Coercion is supposed to be exact (mathematically), so it can not guess anything from an approximate real number. Going from R to QQ is a conversion.
</p>
<pre class="wiki">sage: R = RealField(2)
sage: R.coerce_map_from(QQ)
Generic map:
From: Rational Field
To: Real Field with 2 bits of precision
sage: QQ.coerce_map_from(R)
</pre>
TicketFrédéric ChapotonWed, 15 Nov 2017 15:26:28 GMT
https://trac.sagemath.org/ticket/24219#comment:6
https://trac.sagemath.org/ticket/24219#comment:6
<p>
For your first question, see
</p>
<p>
<a class="ext-link" href="http://doc.sagemath.org/html/en/reference/coercion/index.html"><span class="icon"></span>http://doc.sagemath.org/html/en/reference/coercion/index.html</a>
</p>
<p>
and
</p>
<p>
<a class="ext-link" href="http://doc.sagemath.org/html/en/reference/structure/sage/structure/element.html"><span class="icon"></span>http://doc.sagemath.org/html/en/reference/structure/sage/structure/element.html</a>
</p>
TicketPaul ZimmermannWed, 15 Nov 2017 15:45:23 GMT
https://trac.sagemath.org/ticket/24219#comment:7
https://trac.sagemath.org/ticket/24219#comment:7
<p>
the issue can be simplified to:
</p>
<pre class="wiki">sage: RealField(2)(7) == 10
True
</pre>
TicketJeroen DemeyerThu, 16 Nov 2017 08:49:59 GMTcomponent, description changed
https://trac.sagemath.org/ticket/24219#comment:8
https://trac.sagemath.org/ticket/24219#comment:8
<ul>
<li><strong>component</strong>
changed from <em>basic arithmetic</em> to <em>coercion</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/24219?action=diff&version=8">diff</a>)
</li>
</ul>
<p>
The behaviour that you see is by design, so by definition it's a feature and not a bug.
</p>
<p>
Note also that what you see is consistent with subtraction, which is a good thing:
</p>
<pre class="wiki">sage: RealField(2)(1) - 5/4
0.00
</pre><p>
I don't see a simple fix here... it would require substantial changes to the coercion model.
</p>
TicketPaul ZimmermannThu, 16 Nov 2017 16:23:38 GMT
https://trac.sagemath.org/ticket/24219#comment:9
https://trac.sagemath.org/ticket/24219#comment:9
<blockquote class="citation">
<p>
I don't see a simple fix here...
</p>
</blockquote>
<p>
why no simply forbid comparison involving floating-point numbers, if it can result in mathematically wrong results? Then the user would have to do:
</p>
<pre class="wiki">sage: RealField(2)(7).exact_rational() == 10
False
</pre>
TicketJeroen DemeyerThu, 16 Nov 2017 18:37:14 GMT
https://trac.sagemath.org/ticket/24219#comment:10
https://trac.sagemath.org/ticket/24219#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24219#comment:9" title="Comment 9">zimmerma</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I don't see a simple fix here...
</p>
</blockquote>
<p>
why no simply forbid comparison involving floating-point numbers
</p>
</blockquote>
<p>
I don't think that's realistic. I'm pretty sure that a lot of stuff in Sage would break if we did that.
</p>
TicketTravis ScrimshawThu, 16 Nov 2017 21:53:14 GMT
https://trac.sagemath.org/ticket/24219#comment:11
https://trac.sagemath.org/ticket/24219#comment:11
<p>
I don't quite see it as a mathematically wrong result as it is correct up to the estimate bounds. If we did that, then I feel this would have to return <code>False</code> by the same argument:
</p>
<pre class="wiki">sage: bool(pi.n() == pi)
True
</pre><p>
since <code>pi.n()</code> is an inexact floating point number. Also, we have this doctest in <code>exact_rational</code>:
</p>
<pre class="wiki">sage: RR(3^60).exact_rational() - 3^60
6125652559
</pre>
TicketPaul ZimmermannThu, 16 Nov 2017 22:50:53 GMT
https://trac.sagemath.org/ticket/24219#comment:12
https://trac.sagemath.org/ticket/24219#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/24219#comment:11" title="Comment 11">tscrim</a>:
</p>
<blockquote class="citation">
<p>
I don't quite see it as a mathematically wrong result as it is correct up to the estimate bounds. If we did that, then I feel this would have to return <code>False</code> by the same argument:
</p>
<pre class="wiki">sage: bool(pi.n() == pi)
True
</pre><p>
since <code>pi.n()</code> is an inexact floating point number.
</p>
</blockquote>
<p>
it would indeed be correct to return False, since <code>pi.n()</code> is a well-defined rational number, namely <code>884279719003555/2^48</code>, and it is well known that <code>pi</code> is not rational, thus we cannot get equality.
</p>
<p>
Anyway, since I'm alone to consider this as a bug, I will simply use <code>exact_rational</code> whenever I want correct comparisons with floating-point numbers.
</p>
TicketJeroen DemeyerThu, 08 Mar 2018 10:04:31 GMTstatus, milestone changed; resolution set
https://trac.sagemath.org/ticket/24219#comment:13
https://trac.sagemath.org/ticket/24219#comment:13
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>wontfix</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-8.1</em> to <em>sage-duplicate/invalid/wontfix</em>
</li>
</ul>
Ticket