-1
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;

Murphy Ng
  • 177
  • 7
  • You might be looking for SetPrecision[] instead: SetPrecision[N[π], ∞]. See this as well. – J. M.'s missing motivation May 17 '20 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. – Murphy Ng May 17 '20 at 14:51
  • 1
    Then perhaps you should be comparing ContinuedFraction[N[π]] and ContinuedFraction[Rationalize[N[π], 0]]. Summary: Rationalize[], SetPrecision[], and Round[] all do quite different things. – J. M.'s missing motivation May 17 '20 at 14:56
  • @J.M., No. I need to know why the Rationalize doesn't do what is said in the Doc. If the doc is wrong I need a clear definition of Rationalize – Murphy Ng May 17 '20 at 14:59
  • @Bill I saw it, and how can you say that 3141592653589793/1000000000000000 isn't "close enough" to approPi? It's a strict equal, isn't it? – Murphy Ng May 17 '20 at 15:23
  • 1
    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! – J. M.'s missing motivation May 17 '20 at 15:34
  • @J.M. Thanks. I've read your reference carefully and it's basically irrelevant to my topic. – Murphy Ng May 17 '20 at 15:41
  • 1
    Presumably, in the search for a "nearby rational with small denominator" it stops before it gets to denominators on the order of 10^15 – Bob Hanlon May 17 '20 at 15:49

1 Answers1

1

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. *)
John Doty
  • 13,712
  • 1
  • 22
  • 42
  • 3
    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. – J. M.'s missing motivation May 17 '20 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? – Murphy Ng May 17 '20 at 16:00
  • 2
    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. – J. M.'s missing motivation May 17 '20 at 16:31
  • 4
    @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. – Michael E2 May 17 '20 at 16:54
  • 1
    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. – Daniel Lichtblau May 18 '20 at 14:06
  • So Rationalize[N[Pi], 0] - N[Pi]==0, which apparently satisfy the "close enough" definition of Abs[p/q - x] < 10^-4/q^2. Then, why doesn't Rationalize[N[Pi]] return the same result as Rationalize[N[Pi], 0] do? – Murphy Ng Jun 06 '20 at 04:05
  • @MichaelE2 About "The exact fraction representing approPi internally is given by SetPrecision[apprPi, Infinity]", there is something I feel inconsistent. Or can you please check out my another question? – Murphy Ng Jun 07 '20 at 11:44
  • @MurphyNg You're right. I didn't realize (or forgot) it rounded off the denominator to the nearest power of 2 that can represent the Accuracy[] of the number. You have to extend the accuracy, before setting the precision to infinity. I haven't tracked down the precise extra precision, but this seems sufficient to get a stable result (stable in that increasing the 30 does not change results): SetPrecision[SetPrecision[x, Precision[x]+30], Infinity] – Michael E2 Jun 07 '20 at 17:51