First, 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 and ask question 2444.
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)