1 | initial version |

When 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.

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
```

2 | No.2 Revision |

When you write:

`sage: a=.99999999999999999; `~~b=0.999999999999999999999999999999999~~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.

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
```

3 | No.3 Revision |

When 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

`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
```

4 | No.4 Revision |

When 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

5 | No.5 Revision |

When 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))
True
```

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.