ASKSAGE: Sage Q&A Forum - Individual question feedhttps://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Thu, 09 May 2013 02:47:06 -0500is it a bug?https://ask.sagemath.org/question/10106/is-it-a-bug/the output of the following lines
n=log(64.0)/log(2.0)
print n, range(n)
n=log(N(64))/log(N(2))
print n, range(n)
n=N(log(64)/log(2))
print n, range(n)
is
6.00000000000000 [0, 1, 2, 3, 4, 5]
6.00000000000000 [0, 1, 2, 3, 4, 5]
6.00000000000000 [0, 1, 2, 3, 4]
shouldn't they be all the same?
('Sage Version 5.9, Release Date: 2013-04-30', osx 10.6.8)Thu, 09 May 2013 00:54:14 -0500https://ask.sagemath.org/question/10106/is-it-a-bug/Answer by tmonteil for <p>the output of the following lines</p>
<pre><code>n=log(64.0)/log(2.0)
print n, range(n)
n=log(N(64))/log(N(2))
print n, range(n)
n=N(log(64)/log(2))
print n, range(n)
</code></pre>
<p>is </p>
<pre><code>6.00000000000000 [0, 1, 2, 3, 4, 5]
6.00000000000000 [0, 1, 2, 3, 4, 5]
6.00000000000000 [0, 1, 2, 3, 4]
</code></pre>
<p>shouldn't they be all the same?</p>
<p>('Sage Version 5.9, Release Date: 2013-04-30', osx 10.6.8)</p>
https://ask.sagemath.org/question/10106/is-it-a-bug/?answer=14902#post-id-14902First, when you read `6.00000000000000`, you should understand that this not the value of the number (which is a floating point number having 53 bits of precision), but a string representation of it, as a decimal expansion (not binary). In your third case, the value of `N(log(64)/log(2))` is less that 6 (though very close, hence the decimal representation), as you can check by typing:
sage: a = N(log(64)/log(2))
sage: a < 6
True
sage: a.exact_rational()
6755399441055743/1125899906842624
sage: a.sign_mantissa_exponent()
(1, 6755399441055743, -50)
In the first two cases, you can check that the first two values are equal to `6`.
Now, where could this difference come from ? The first two values are the same since `N(64)` is just the conversion of the integer `64` into an element of `RealField(53)`, which is the same as `64.0`. What about the third ? `log(64)/log(2)` is not a floating point number but an element of the `Symbolic Ring`, as you can check by typing:
sage: (log(64)/log(2)).parent()
Symbolic Ring
Now, when you type `N(log(64)/log(2))`, you ask Sage to convert this element of the `Symbolic Ring` to an element of `RealField(53)`. Hence, it seems that the rounding from the `Symbolic Ring` to `RealField(53)` is not done to the nearest floating point number, but toward zero:
sage: N(log(64)/log(2)) < 6
True
sage: N(-log(64)/log(2)) > -6
True
It looks like to be a similar problem that the one that appeared for the conversion from the `Rational Field` to the `Real Double Field`, see [trac ticket 14416](http://trac.sagemath.org/sage_trac/ticket/14416) and [ask question 2444](http://ask.sagemath.org/question/2444/what-are-the-differences-between-realdoublefield).
What is weird is that the `Symbolic Ring` is able to understand that $64 = 2^6$ and find the right result by itself:
sage: a = log(64)/log(2)
sage: a.full_simplify()
6
sage: N((log(64)/log(2)).full_simplify()) == 6.0
True
The main advice i could do is to avoid the use of `Symbolic Ring` as much as possible (see for example [this problem with powers of complex numbers](http://ask.sagemath.org/question/2518/get-variants-of-complex-cube-root#3451))
Thu, 09 May 2013 01:23:51 -0500https://ask.sagemath.org/question/10106/is-it-a-bug/?answer=14902#post-id-14902Comment by abc for <p>First, when you read <code>6.00000000000000</code>, you should understand that this not the value of the number (which is a floating point number having 53 bits of precision), but a string representation of it, as a decimal expansion (not binary). In your third case, the value of <code>N(log(64)/log(2))</code> is less that 6 (though very close, hence the decimal representation), as you can check by typing:</p>
<pre><code>sage: a = N(log(64)/log(2))
sage: a < 6
True
sage: a.exact_rational()
6755399441055743/1125899906842624
sage: a.sign_mantissa_exponent()
(1, 6755399441055743, -50)
</code></pre>
<p>In the first two cases, you can check that the first two values are equal to <code>6</code>.</p>
<p>Now, where could this difference come from ? The first two values are the same since <code>N(64)</code> is just the conversion of the integer <code>64</code> into an element of <code>RealField(53)</code>, which is the same as <code>64.0</code>. What about the third ? <code>log(64)/log(2)</code> is not a floating point number but an element of the <code>Symbolic Ring</code>, as you can check by typing: </p>
<pre><code>sage: (log(64)/log(2)).parent()
Symbolic Ring
</code></pre>
<p>Now, when you type <code>N(log(64)/log(2))</code>, you ask Sage to convert this element of the <code>Symbolic Ring</code> to an element of <code>RealField(53)</code>. Hence, it seems that the rounding from the <code>Symbolic Ring</code> to <code>RealField(53)</code> is not done to the nearest floating point number, but toward zero:</p>
<pre><code>sage: N(log(64)/log(2)) < 6
True
sage: N(-log(64)/log(2)) > -6
True
</code></pre>
<p>It looks like to be a similar problem that the one that appeared for the conversion from the <code>Rational Field</code> to the <code>Real Double Field</code>, see <a href="http://trac.sagemath.org/sage_trac/ticket/14416">trac ticket 14416</a> and <a href="http://ask.sagemath.org/question/2444/what-are-the-differences-between-realdoublefield">ask question 2444</a>.</p>
<p>What is weird is that the <code>Symbolic Ring</code> is able to understand that $64 = 2^6$ and find the right result by itself:</p>
<pre><code>sage: a = log(64)/log(2)
sage: a.full_simplify()
6
sage: N((log(64)/log(2)).full_simplify()) == 6.0
True
</code></pre>
<p>The main advice i could do is to avoid the use of <code>Symbolic Ring</code> as much as possible (see for example <a href="http://ask.sagemath.org/question/2518/get-variants-of-complex-cube-root#3451">this problem with powers of complex numbers</a>)</p>
https://ask.sagemath.org/question/10106/is-it-a-bug/?comment=17729#post-id-17729I do not understand your last comment: If it is a problem with the conversion to the real field, then why is it wired that the symbolic ring works well? Thu, 09 May 2013 02:18:10 -0500https://ask.sagemath.org/question/10106/is-it-a-bug/?comment=17729#post-id-17729Comment by tmonteil for <p>First, when you read <code>6.00000000000000</code>, you should understand that this not the value of the number (which is a floating point number having 53 bits of precision), but a string representation of it, as a decimal expansion (not binary). In your third case, the value of <code>N(log(64)/log(2))</code> is less that 6 (though very close, hence the decimal representation), as you can check by typing:</p>
<pre><code>sage: a = N(log(64)/log(2))
sage: a < 6
True
sage: a.exact_rational()
6755399441055743/1125899906842624
sage: a.sign_mantissa_exponent()
(1, 6755399441055743, -50)
</code></pre>
<p>In the first two cases, you can check that the first two values are equal to <code>6</code>.</p>
<p>Now, where could this difference come from ? The first two values are the same since <code>N(64)</code> is just the conversion of the integer <code>64</code> into an element of <code>RealField(53)</code>, which is the same as <code>64.0</code>. What about the third ? <code>log(64)/log(2)</code> is not a floating point number but an element of the <code>Symbolic Ring</code>, as you can check by typing: </p>
<pre><code>sage: (log(64)/log(2)).parent()
Symbolic Ring
</code></pre>
<p>Now, when you type <code>N(log(64)/log(2))</code>, you ask Sage to convert this element of the <code>Symbolic Ring</code> to an element of <code>RealField(53)</code>. Hence, it seems that the rounding from the <code>Symbolic Ring</code> to <code>RealField(53)</code> is not done to the nearest floating point number, but toward zero:</p>
<pre><code>sage: N(log(64)/log(2)) < 6
True
sage: N(-log(64)/log(2)) > -6
True
</code></pre>
<p>It looks like to be a similar problem that the one that appeared for the conversion from the <code>Rational Field</code> to the <code>Real Double Field</code>, see <a href="http://trac.sagemath.org/sage_trac/ticket/14416">trac ticket 14416</a> and <a href="http://ask.sagemath.org/question/2444/what-are-the-differences-between-realdoublefield">ask question 2444</a>.</p>
<p>What is weird is that the <code>Symbolic Ring</code> is able to understand that $64 = 2^6$ and find the right result by itself:</p>
<pre><code>sage: a = log(64)/log(2)
sage: a.full_simplify()
6
sage: N((log(64)/log(2)).full_simplify()) == 6.0
True
</code></pre>
<p>The main advice i could do is to avoid the use of <code>Symbolic Ring</code> as much as possible (see for example <a href="http://ask.sagemath.org/question/2518/get-variants-of-complex-cube-root#3451">this problem with powers of complex numbers</a>)</p>
https://ask.sagemath.org/question/10106/is-it-a-bug/?comment=17728#post-id-17728When you write N(log(64)/log(2)), actually you call the method `.n()` of the object `log(64)/log(2)`, which is an element of the `Symbolic Ring`.
sage: N??
sage: a = log(64)/log(2)
sage: a.n() == N(a)
True
Hence the conversion problem should be attributed to the class `sage.symbolic.expression.Expression`.
However, this class also has a method `.full_simplify()`, which does some formal simplifications (here it understands that `64=2^6` and `log(a^b) = b.log(a)`, and, when it is called before `.n()`, it alows to find the correct rounding:
sage: (log(64)/log(2)).n() == 6
False
sage: (log(64)/log(2)).full_simplify().n() == 6
True
which is a kind of inconsistency.
Thu, 09 May 2013 02:47:06 -0500https://ask.sagemath.org/question/10106/is-it-a-bug/?comment=17728#post-id-17728