1 | initial version |

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, 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 the `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 the same problem that appeared for the conversion from the `Rational Field`

to the `Real Double Field`

, see trac ticket 14416 and ask question 2444.

2 | No.2 Revision |

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, ~~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 ~~the ~~`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 ~~the same ~~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.

3 | No.3 Revision |

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)

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.