# About the Rationalize of an approximated number

In[3]:= Clear["*"];
approPi = N[Pi];
{Rationalize[approPi], Round[approPi, 10^-15]}

Out[2]= {3.14159, 3141592653589793/1000000000000000}


Above Rationalize failed to give a rational number probably because that, according to the Doc, there is no rational number "close enough" to approPi. But apparently there exists a "close enough" rational number which is given by Round;

I know I can use Rationalize[x,dx] in this situation, according to the Doc:

Rationalize[x,dx]: yields the rational number with smallest denominator that lies within dx of x.

So below:

In[4]:= Clear["*"];
approPi = N[Pi];
{Rationalize[approPi, 0], Round[approPi, 10^-15]}
N[%, 20]

Out[2]= {245850922/78256779, 3141592653589793/1000000000000000}

Out[3]= {3.1415926535897931603, 3.1415926535897930000}


However, the error dx in the result 245850922/78256779 is by no means 0. Because 245850922/78256779, ie 3.1415926535897931603..., has the unnecessary 0.0000000000000001603 in it.

The result 3141592653589793/1000000000000000 of Round is the exact rational number equal to approPi. So I think the 3141592653589793/1000000000000000 I got via Round should be what Rationalize[approPi, 0] is supposed to output according to the Doc;

• You might be looking for SetPrecision[] instead: SetPrecision[N[π], ∞]. See this as well. May 17, 2020 at 14:45
• No, I'm not looking for any way to convert an decimal fraction to rationals. I'm looking for an explanation rather then a way. An explanation about Rationalize's strange behavior. @J.M. May 17, 2020 at 14:51
• Then perhaps you should be comparing ContinuedFraction[N[π]] and ContinuedFraction[Rationalize[N[π], 0]]. Summary: Rationalize[], SetPrecision[], and Round[] all do quite different things. May 17, 2020 at 14:56
• I was telling you what to look at so you could hopefully figure out an answer to your own question. Oh well, good luck with getting an answer! May 17, 2020 at 15:34
• Presumably, in the search for a "nearby rational with small denominator" it stops before it gets to denominators on the order of 10^15 May 17, 2020 at 15:49

Under "Details" the documentation states:

Rationalize[x,0] converts any inexact number x to rational form.

In fact, it yields a rational number that when converted back to approximate, is within the precision bounds of the approximate number, and often the difference is 0.. This is reasonable and useful behavior.

Rationalize[N[Pi], 0] - N[Pi]
(* 0. *)

• More precisely put: Rationalize[] works with the CF expansion of an inexact number, and returns the convergent whose difference with the input is less than or equal to the tolerance. May 17, 2020 at 15:44
• @J.M. So the reason why Rationalize[] failed to give a prefect matched rational number to target number is because it's lazy? Here I assume the target number is approPi  seen as an exact number, ie 3.141592653589793. But dx specified here is 0, how is an inaccurate result of 245850922/78256779 given? May 17, 2020 at 16:00
• I already told you to look at the continued fraction, but you did not and thought it was irrelevant. I'll leave this to you to think about, @Murphy. May 17, 2020 at 16:31
• @MurphyNg (1) The exact fraction representing approPi internally is given by SetPrecision[apprPi, Infinity] -- it will have a denominator that is a power of 2 not 10, since internally, floating-point is binary on (almost all) computers. (2) From the docs Rationalize[x] returns p/q such that Abs[p/q - x] < 10^-4/q^2, if such a p/q exists. And Rationalize[x, 0] is a special case that does what J.M. has indicated. It will usually return the same thing as Rationalize[N[x], x*\$MachineEpsilon/2], but there are edge cases that might be different. May 17, 2020 at 16:54
• This has been answered three times now (by John Doty, J.M., and Michael E2). The point is that the difference between rationalized result and inpu is 0 to all digits of precision. As for the "leftover" digits, that's an inevitable consequence of the fact that most binary numbers require more decimal digits to express than their precision warrants (stated differently, decimal-to-binary-to-decimal does not round-trip unless the input is exactly representable in both bases). I may vote to close this as a misunderstanding of the underlying math rather than a Mathematica issue per se. May 18, 2020 at 14:06