Ask Your Question
2

Issues with .99999999999...

asked 2016-12-09 12:00:48 +0100

mf gravatar image

updated 2023-01-09 23:59:41 +0100

tmonteil gravatar image

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
edit retag flag offensive close merge delete

Comments

I believe this is due to number of precision http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_mpfr.html It might be a good idea to work with RealField

A.Alharbi gravatar imageA.Alharbi ( 2016-12-09 12:09:57 +0100 )edit
1

@A.Alharbi they are already elements of some RealField (with various precisions).

tmonteil gravatar imagetmonteil ( 2016-12-09 13:20:05 +0100 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2016-12-09 13:28:12 +0100

tmonteil gravatar image

updated 2017-04-11 03:18:27 +0100

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

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
edit flag offensive delete link more

Comments

In 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??
eric_g gravatar imageeric_g ( 2016-12-09 13:47:02 +0100 )edit

Besides, 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.

eric_g gravatar imageeric_g ( 2016-12-09 13:57:02 +0100 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2016-12-09 12:00:48 +0100

Seen: 1,183 times

Last updated: Apr 11 '17