In this section

Rational Approximations to ln(2)

The exponential logarithm "ln(1+x)" can be approximated by the series

ln(1+x) = x - x2/2 + x3/3 - x4/4 ...

So to calculate ln(2) we can substitute x=1 and get the following series of approximations

ln(2) is approximately 0.69314718 so this calculation looks like it could take a long time to get there. Using this to calculate ln(3) is even worse, as the series diverges. The series converges much faster for smaller 'x' values, so to improve the convergence rate we need to find an expression involving values closer to 1. We we can make substitutions like

2 = (3/2) * (4/3)
⇒ ln(2) = ln(3/2) + ln(4/3)

How this converges can be seen in the next table.

This is significantly better as it has achieved 4 decimal places after 10 terms, the previous equation barely achieved 1. We can derive even faster converging equations, by making additional substitutions like

ln(3/2) = ln(4/3) + ln(9/8)
⇒ ln(2)   = 2 * ln(4/3) + ln(9/8)

This converges a bit faster than the previous series, but not spectacularly so, at the expense of generating much larger integers in the rational representation.

Calculating ln(3)/ln(2)

To calculate ln(3) / ln(2) we notice that

ln(3) = ln(3/2) + ln(2)

which leads to

ln(2) = ln(3/2) + ln(4/3)ln(3)/ln(2) = 1 + ln(3/2) / ln(2)

This isn't very good as we still have the slowly converging log(2) to calculate. But

ln(2) = ln(3/2) + ln(4/3)
⇒ ln(3)/ln(2) = 1 + ln(3/2) / (ln(3/2) + ln(4/3))

Calculating this gives

This converges quite quickly with the error roughly halving for each extra term. The expected value is about 1.58496250072116. We can though make the additional substitution

ln(3/2) = ln(4/3) + ln(9/8)
⇒ ln(3)/ln(2) = 2 - ln(4/3)/(2 * ln(4/3) + ln(9/8))

Which will converge even faster as 1 < 9 / 8 < 4 / 3 but with the same drawbacks found when calculating ln(2).

Factorising 2

The above calculations depend on factorising 2 into ever smaller pieces. If this factorisation follows a predictable path we can generate a series that converges very quickly. The first 10 factorisations are shown in the following table. The "1 / (x-1)" gives an indication of the rate of convergence, so each term in the ln(2) = 41*ln(G) + 12*ln(J) summation would reduce the error by a factor of about 70 (based on G).

The product is is always of the form

(2a/3b)c * (3e/2f)g = 2(a*c - f*g)/3(f*g - b*c) = 2
⇒ a*c = f*g + 1 and b*c = e*g

If we sum the first 5 terms of ln(2) = 41*log(G) + 12*ln(J) we get 0.693147180608, which compares quite well with the floating point version 0.6931471805599. Unfortunately, the 2 integers involved in forming this ratio are rather large: 2.953...*10127 and 4.261...*10127.

ln(3) / ln(2) revisited

The methods in the previous section can give us arbitrarily accurate rational approximations to ln(3) / ln(2), but only at the expense of dealing with unmanageably large integers. Curiously, though as the factors (2a / 3b) and (3e / 2f) get closer to one the ratios a / b and f / e get to closer ln(3) / ln(2), and obey the relation

a/b > ln(3)/ln(2) > f/e

We can calculate a, b, e and f using the following Python script. A javascript version can be found in the associated script "log3over2.js".

def findFactors(limit):

    a = 2
    b = 1
    e = b
    f = a-1

    for i in range (limit):
        m = a + f
        n = b + e
        m2 = 2**m
        n2 = 3**n

        if m2 > n2:
            a = m
            b = n
        else:
            e = n
            f = m

The next table shows the first 49 iterations of this script. The blue cells show which value has changed since the previous row.

ln(3) / ln(2) =~ 1.58496250072116, so after 49 iterations we have fractions that are indistinguishable from the floating point version. The a/b values converge on log(3) / log(2) from above and the f / e values from below. It is the a / b values that will be useful in deriving limits to where the loops might be in 3x+1.

When we get a particularly good value (like f / e = 1054 / 665) the other value (a/b) takes some time to catch up, see rows 17 to 39.

Although this appears to be an easy way to find integer approximations to ln(3) / ln(2) it suffers from two drawbacks:

You can use the following controls to explore alternative routes to log(3)/log(2). "Limit" controls the number of iterations. You could theoretically reproduce the table above but you may be waiting a long time. A: B: Limit: Go

Are these the best?

We seeded the Python script in the previous section with 22 / 31. In fact any seed of the form 2a / 3b in the range 1-2 would do. The next smallest unused value is 24/32 = 16 / 9 = 1.777... This is a bit high, but let's see what happens.

Here a+f = 7424107 and 27424107 will have something like 2234878 digits. My PC nearly ground to a halt calculating these.

None of the values generated by 16 / 9 are better than those for 4 / 3. 32 / 9, 128 / 81 and 4096 / 2187 didn't produce any better values either.

Other pages