ASKSAGE: Sage Q&A Forum - Individual question feedhttp://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Fri, 09 Dec 2016 06:57:02 -0600Issues with .99999999999...http://ask.sagemath.org/question/35963/issues-with-99999999999/ Here is a result that I found surprising and I don't understand completely what corercian is causing it.
sage: int(.9999999999999999)
0
sage: int(.99999999999999999)
1
sage: int(0.99999999999999999)
0
sage: int(0.9999999999999999)
0
sage: int(0.999999999999999999999999999999999)
0
What is going on?
More to play with:
sage: a=.99999999999999999; b=0.999999999999999999999999999999999
sage: a<b
False
sage: int(a)<int(b)
False
and
sage: a=.999999999999999990; b=0.999999999999999999999999999999999
sage: int(a)<int(b)
False
sage: a<b
True
sage: a=.999999999999999997
sage: a<b
False
sage: a=.999999999999999996
sage: a<b
True
Fri, 09 Dec 2016 05:00:48 -0600http://ask.sagemath.org/question/35963/issues-with-99999999999/Comment by tmonteil for <p>Here is a result that I found surprising and I don't understand completely what corercian is causing it.</p>
<pre><code>sage: int(.9999999999999999)
0
sage: int(.99999999999999999)
1
sage: int(0.99999999999999999)
0
sage: int(0.9999999999999999)
0
sage: int(0.999999999999999999999999999999999)
0
</code></pre>
<p>What is going on? </p>
<p>More to play with:</p>
<pre><code>sage: a=.99999999999999999; b=0.999999999999999999999999999999999
sage: a<b
False
sage: int(a)<int(b)
False
</code></pre>
<p>and </p>
<pre><code>sage: a=.999999999999999990; b=0.999999999999999999999999999999999
sage: int(a)<int(b)
False
sage: a<b
True
sage: a=.999999999999999997
sage: a<b
False
sage: a=.999999999999999996
sage: a<b
True
</code></pre>
http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35966#post-id-35966@A.Alharbi they are already elements of some RealField (with various precisions).Fri, 09 Dec 2016 06:20:05 -0600http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35966#post-id-35966Comment by A.Alharbi for <p>Here is a result that I found surprising and I don't understand completely what corercian is causing it.</p>
<pre><code>sage: int(.9999999999999999)
0
sage: int(.99999999999999999)
1
sage: int(0.99999999999999999)
0
sage: int(0.9999999999999999)
0
sage: int(0.999999999999999999999999999999999)
0
</code></pre>
<p>What is going on? </p>
<p>More to play with:</p>
<pre><code>sage: a=.99999999999999999; b=0.999999999999999999999999999999999
sage: a<b
False
sage: int(a)<int(b)
False
</code></pre>
<p>and </p>
<pre><code>sage: a=.999999999999999990; b=0.999999999999999999999999999999999
sage: int(a)<int(b)
False
sage: a<b
True
sage: a=.999999999999999997
sage: a<b
False
sage: a=.999999999999999996
sage: a<b
True
</code></pre>
http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35964#post-id-35964I believe this is due to number of precision [http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html](http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html) It might be a good idea to work with RealFieldFri, 09 Dec 2016 05:09:57 -0600http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35964#post-id-35964Answer by tmonteil for <p>Here is a result that I found surprising and I don't understand completely what corercian is causing it.</p>
<pre><code>sage: int(.9999999999999999)
0
sage: int(.99999999999999999)
1
sage: int(0.99999999999999999)
0
sage: int(0.9999999999999999)
0
sage: int(0.999999999999999999999999999999999)
0
</code></pre>
<p>What is going on? </p>
<p>More to play with:</p>
<pre><code>sage: a=.99999999999999999; b=0.999999999999999999999999999999999
sage: a<b
False
sage: int(a)<int(b)
False
</code></pre>
<p>and </p>
<pre><code>sage: a=.999999999999999990; b=0.999999999999999999999999999999999
sage: int(a)<int(b)
False
sage: a<b
True
sage: a=.999999999999999997
sage: a<b
False
sage: a=.999999999999999996
sage: a<b
True
</code></pre>
http://ask.sagemath.org/question/35963/issues-with-99999999999/?answer=35967#post-id-35967When you write:
sage: a=.99999999999999999; b=0.999999999999999999999999999999999
You should understand that, while they have an exact *decimal* representation, those numbers can not be written in *binary* form exactly (i.e. there are no integers `p` and `q` such that `a=p/2^q`). So, when Sage transforms them into floating-point numbers, it has to round them. Since the rounding is done toward the closest floating-point number (with some given precision), sompetimes it is rounded from below, sometimes from above. When two numbers `a<b` are converted to floating point *with the same precision*, of course the corresponding floating-point numbers are ordered in a monotonic way. There is no reason why it should be the case when the numbers are rounded with different precisions, since increasing the precision adds some new floating-point numbers inbetween to which `b` will be rounded.
Here is some Sage code to understand your issue:
sage: a.parent()
Real Field with 54 bits of precision
sage: b.parent()
Real Field with 110 bits of precision
sage: a.sign_mantissa_exponent()
(1, 9007199254740992, -53)
sage: a.exact_rational()
1
sage: b.sign_mantissa_exponent()
(1, 1298074214633706907132624082305023, -110)
sage: b.exact_rational()
1298074214633706907132624082305023/1298074214633706907132624082305024
**EDIT**: It turns out that there was a bug with the way Sage currently deals with `.999...` vs `0.999...`, see https://groups.google.com/forum/#!msg/sage-devel/KhaL5hX08uM/jUq9lTHZCgAJ
Without this weird behaviour, things are ordered correctly:
sage: all(RealNumber('0.'+'9'*i) < RealNumber('0.'+'9'*(i+1)) for i in range(3,1000))
True
sage: all(RealNumber('0.'+'9'*i) < RealNumber('0.'+'9'*j) for i in range(3,100) for j in range(i+1,100))
TrueFri, 09 Dec 2016 06:28:12 -0600http://ask.sagemath.org/question/35963/issues-with-99999999999/?answer=35967#post-id-35967Comment by eric_g for <p>When you write:</p>
<pre><code>sage: a=.99999999999999999; b=0.999999999999999999999999999999999
</code></pre>
<p>You should understand that, while they have an exact <em>decimal</em> representation, those numbers can not be written in <em>binary</em> form exactly (i.e. there are no integers <code>p</code> and <code>q</code> such that <code>a=p/2^q</code>). So, when Sage transforms them into floating-point numbers, it has to round them. Since the rounding is done toward the closest floating-point number (with some given precision), sompetimes it is rounded from below, sometimes from above. When two numbers <code>a<b</code> are converted to floating point <em>with the same precision</em>, of course the corresponding floating-point numbers are ordered in a monotonic way. There is no reason why it should be the case when the numbers are rounded with different precisions, since increasing the precision adds some new floating-point numbers inbetween to which <code>b</code> will be rounded.</p>
<p>Here is some Sage code to understand your issue:</p>
<pre><code>sage: a.parent()
Real Field with 54 bits of precision
sage: b.parent()
Real Field with 110 bits of precision
sage: a.sign_mantissa_exponent()
(1, 9007199254740992, -53)
sage: a.exact_rational()
1
sage: b.sign_mantissa_exponent()
(1, 1298074214633706907132624082305023, -110)
sage: b.exact_rational()
1298074214633706907132624082305023/1298074214633706907132624082305024
</code></pre>
<p><strong>EDIT</strong>: It turns out that there was a bug with the way Sage currently deals with <code>.999...</code> vs <code>0.999...</code>, see <a href="https://groups.google.com/forum/#!msg/sage-devel/KhaL5hX08uM/jUq9lTHZCgAJ">https://groups.google.com/forum/#!msg...</a></p>
<p>Without this weird behaviour, things are ordered correctly:</p>
<pre><code>sage: all(RealNumber('0.'+'9'*i) < RealNumber('0.'+'9'*(i+1)) for i in range(3,1000))
True
sage: all(RealNumber('0.'+'9'*i) < RealNumber('0.'+'9'*j) for i in range(3,100) for j in range(i+1,100))
True
</code></pre>
http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35969#post-id-35969Besides, the example
sage: a=.99999999999999999; b=0.999999999999999999999999999999999
sage: a<b
False
is not so surprising if you print out `a-1` and `b-1`:
sage: a-1
0.000000000000000
sage: b-1
-7.7037197775489434122239117703397e-34
It is then mathematically correct that `a<b`.Fri, 09 Dec 2016 06:57:02 -0600http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35969#post-id-35969Comment by eric_g for <p>When you write:</p>
<pre><code>sage: a=.99999999999999999; b=0.999999999999999999999999999999999
</code></pre>
<p>You should understand that, while they have an exact <em>decimal</em> representation, those numbers can not be written in <em>binary</em> form exactly (i.e. there are no integers <code>p</code> and <code>q</code> such that <code>a=p/2^q</code>). So, when Sage transforms them into floating-point numbers, it has to round them. Since the rounding is done toward the closest floating-point number (with some given precision), sompetimes it is rounded from below, sometimes from above. When two numbers <code>a<b</code> are converted to floating point <em>with the same precision</em>, of course the corresponding floating-point numbers are ordered in a monotonic way. There is no reason why it should be the case when the numbers are rounded with different precisions, since increasing the precision adds some new floating-point numbers inbetween to which <code>b</code> will be rounded.</p>
<p>Here is some Sage code to understand your issue:</p>
<pre><code>sage: a.parent()
Real Field with 54 bits of precision
sage: b.parent()
Real Field with 110 bits of precision
sage: a.sign_mantissa_exponent()
(1, 9007199254740992, -53)
sage: a.exact_rational()
1
sage: b.sign_mantissa_exponent()
(1, 1298074214633706907132624082305023, -110)
sage: b.exact_rational()
1298074214633706907132624082305023/1298074214633706907132624082305024
</code></pre>
<p><strong>EDIT</strong>: It turns out that there was a bug with the way Sage currently deals with <code>.999...</code> vs <code>0.999...</code>, see <a href="https://groups.google.com/forum/#!msg/sage-devel/KhaL5hX08uM/jUq9lTHZCgAJ">https://groups.google.com/forum/#!msg...</a></p>
<p>Without this weird behaviour, things are ordered correctly:</p>
<pre><code>sage: all(RealNumber('0.'+'9'*i) < RealNumber('0.'+'9'*(i+1)) for i in range(3,1000))
True
sage: all(RealNumber('0.'+'9'*i) < RealNumber('0.'+'9'*j) for i in range(3,100) for j in range(i+1,100))
True
</code></pre>
http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35968#post-id-35968In complement to @tmonteil's answer, you may have a look at what Sage's is doing when you enter `a=.99999999999999999`: it converts the string `".99999999999999999"` to a real number of finite precision, the latter being determined by the length of the string. Indeed Sage's preparser is invoking the function `RealNumber`:
sage: preparse("a=.99999999999999999")
"a=RealNumber('.99999999999999999')"
and you can have a look at what this function is doing via
sage: RealNumber??Fri, 09 Dec 2016 06:47:02 -0600http://ask.sagemath.org/question/35963/issues-with-99999999999/?comment=35968#post-id-35968