# What is the best way to calculate log without a calculator?

As the title states, I need to be able to calculate logs on paper without a calculator.

For example, how would I calculate $\log(25)$?

• If you can calculate $\log p$ for every prime, you can calculate $\log x$ for every $x \in \mathbb{Q}_+$. – Michael Albanese Jun 4 '14 at 5:22
• yes it is base 10. Sorry I didnt mention that. – Ogen Jun 4 '14 at 5:26
• If you know the values of $\log p$ for every prime, these can be used to determine the logarithm of any positive rational number just by using the rules $\log(a^b) = b\log a$ and $\log(ab) = \log(a) + \log(b)$. – Michael Albanese Jun 4 '14 at 5:37
• I happen to remember that $\log(2) = 0.30103$ to about 8 decimal places. So $\log(25) \approx 2 - 2\times 0.30103$. – Stephen Montgomery-Smith Jun 4 '14 at 6:11
• If I was going to memorize $\log(2)$, I would use $125 \sim 128$ for this problem. – user14972 Jun 4 '14 at 6:27

This is a method I found a year ago. This method takes a lot of time but it will give an accurate answer.
To calculate log(25):
1) Divide 25 by the nearest power of 10. The condition must be 25 ≥ 10n.
2) The value of n is 1 because 25 ≥ 101. So the initial answer is 1.xxxxxx.
3) Divide 25 by 101. The result is 2.5.
4) Raise 2.5 by 10. So 2.510 ≈ 9536.7
(Note: The number is raised to 10 because we are already looking for the digits after the decimal point.)
5) For the next values, the same process will be used.
6) Divide 9536.7 by the nearest power of 10.
7) 9536.7 ≥ 103 so n=3. The answer is now 1.3xxxxx.
8) 9536.7 / 103 = 9.5367
9) Raise 9.5367 to 10. 9.536710 = 6222733625
10) 6222733625 ≥ 10n so n=9. The answer is now 1.39xxxx.
11) Repeat the same process until you get the desired precision.
12) So log (25) ≈ 1.39794.

This also works on logs with bases other than 10, even with decimals. In solving loga(x), just replace 10n with an. Also in solving for n, simply just divide the number by the base repeatedly until you get a quotient nearest to 1. The number of times you divided is n. (ie. 250/10= 25 (1), 25/10=2.5 (2), so n=2)

This is a method I had formulated on my own so I'm not saying that this is 100% reliable. It would be better to check your answer with a calculator. But I've tried this many times without flaws. No log tables, no need to memorize, just pure math.

• Your algorithm is 100% reliable. I gave an answer explaining why ... – String Mar 8 '15 at 21:12
• This is great. I tried writing this algorithm into a programming language called Elisp and it started to produce incorrect results after about 20 decimals points. It's not clear to me though exactly why it starts failing after that. If @String is correct in his proof, then I'm assuming it's a technical fault on my end (maybe float-arithmetic errors, but I'm not sure. You can see my code here: github.com/keanedawg/elisp-precision-logarithm – Cameron May 24 '17 at 15:01
• @Wilddog: The problem is with float-arithmetic, I am sure! To avoid this, one could convert the computations to the format $$x=n\cdot 10^p$$ where $n,p$ are integers. Thus in step 1. we find $d$ as the largest power of $10$ less than or equal to $n$ but then we add $p$ to it, and instead of using $y=x/10^d$, we use $$y=n\cdot 10^{p-d}$$ and finally we update $x$ as $$x=y^{10}=n^{10}\cdot 10^{10(p-d)}$$ – String May 26 '17 at 12:42
• @Wilddog: But you will need infinite precision integer arithmetic for that approach to work. I do not know whether Elisp provides that or not, otherwise you could program it yourself. – String May 26 '17 at 12:46
• This algorithm is good to maybe 5 decimal places. Ultimately it fails because of the limited precision of your calculator, Knuth offers a similar algorithm that uses squaring and gives the digits in binary, and also gives as a problem investigation of the error. – richard1941 Jul 4 '17 at 14:06

Calculating them to high precision is tedious, which is why the tables were once so important. The tables relied on interpolation formulae and inevitably contained errors, carried from book to book as a result of silent copying, sometimes for 200 years or more; errors in Vlacq and de Decker's table (1627) were still turning up in tables in the 19th century. This was one of Babbage's motivations for trying to construct a general purpose computer. Luckily, estimating a logarithm reliably to three or four decimal places isn't too hard if you are willing to memorize a handful of values and a simple formula.

Memorize $\log_{10}2,3,5,7$ and $\tfrac1{\ln10}\approx0.4343$.

(Note that $\log_{10}5=1-\log_{10}2$.) Then use $$\ln x\approx2\cdot\tfrac{x-1}{x+1}\text{ for }x\approx1$$ So for example $\log_{10}17=\log_{10}(2^4\cdot\tfrac{17}{16})=4\log_{10}2+\tfrac1{\ln10}\cdot\ln\tfrac{17}{16}$

And that's about $4\cdot0.30103+0.4343\cdot2\cdot\tfrac1{33}=1.23044\overline{12}$. True value: $1.2304489...$

Similarly $\log_{10}22=\log_{10}(3\cdot 7\cdot \tfrac{22}{21})=\log_{10}3+\log_{10}7+\tfrac1{\ln 10}\cdot\ln\tfrac{22}{21}$

Approximately $0.477121+0.845098+0.4343\cdot2\cdot\tfrac1{43}=1.342419$. True value: $1.34242268...$

Something like $\log_{10}3.57$ can be calculated as $-2+\log_{10}357$ which you can expand as $=-2+\log_{10}3+\log_{10}7+\log_{10}17\approx 0.55266$. True value: $0.5526682...$ In general the level of accuracy depends on how far you want to go in memorizing the logarithms of prime numbers.

• If you know the log of a few prime numbers, you can find the log of a number that is close to the desired one. So if you have log(x) and you want log(x+d), just add 0.4343*d/(x+d/2) to log(x) and you will be close enough for gubbermint work. Example: compute log(10). We know that 2^10 = 1024, so log(1000)= 10*log(2)-log(1.024) = 3.01030-.4343*.024/1.012 = 3.000000. Divide this by 3 to get log(10)=1.000000. So you can usually do OK knowing only log(2) and log(e). Memorize log(3) if you are ambitious. – richard1941 Jul 4 '17 at 6:57
• I have found that the above formula, d/(x+d/2), is superior to linear interpolation and to 4 point Lagrange interpolation of the table in AMS 55. – richard1941 Jul 4 '17 at 7:02

In case anybody wondered why the algorithm given by Ezui actually works, here is a little algebra to explain why:

The algorithm states, that to find the base $10$ logarithm of $x$ one should repeatedly carry out the following three steps:

1. $d=\max(n\mid 10^n\leq x)$, store $d$ as the next digit
2. $y=x/10^d$
3. $x=y^{10}$

To prove the correctness, it suffices to prove that each "round" is correct. For simplicity, let $\log$ denote the base $10$ logarithm. First note that $d=\lfloor\log(x)\rfloor\in[0,\infty)\cap\mathbb Z$ is the integer part of $\log(x)$ and then \begin{align} \log(y)&=\log(x/10^d)\\ &=\log(x)-d\in[0,1) \end{align} where $\log(y)$ must be the fractional part of $\log(x)$. Thus we have $\log(x)=d+\log(y)$. Now, $\log(y^{10})=10\log(y)\in[0,10)$, so if determine $\log(y^{10})$ this result may be used to compute $\log(x)=d+\log(y^{10})/10$. The first digit of $\log(y^{10})$ is found in step 1. in the next "round" of the algorithm where $x=y^{10}$. So the algorithm is correct and produces a new digit of $\log(x)$ in each step.

For calculating $\log_b(x)$, the algorithm should be:

1. $d=\max(n\mid b^n\leq x)$, store $d$ as the next digit
2. $y=x/b^d$
3. $x=y^b$

Use the power series $ln(y) = -ln(1-x) = \sum_{k=1}^{\infty}\frac{x^k}{k}$ with $y=\frac{1}{1-x}$. For x<1 or y>1 respectively the sum converges.

To get to a different base like 10 use the relation $log_n(x) = \frac{ln(x)}{ln(n)}$

A neat trick is to first reduce the problem to calculating the log of a number that's very close to 1, then use $\log{(1+x)}=\log{\frac{1+y}{1-y}}$ where $y=\frac{x}{2+x}$. Then use $$\log{\frac{1+y}{1-y}} = 2\sum_{n=0}^\infty\frac{y^{2n+1}}{2n+1}$$

This method is good because the error term converges much faster in the second expansion.

For example, $\log{2}=\log{\frac{1+1/3}{1-1/3}}=\log{\frac{1+1/7}{1-1/7}}-\log{\frac{1+(-1/5)}{1-(-1/5)}}=\log{\frac{1+1/7}{1-1/7}}+\log{\frac{1+1/5}{1-1/5}}$

Then $\log{\frac{1+1/7}{1-1/7}}= 2(1/7+1/(3\times7^3)+\cdots)$, $\log{\frac{1+1/5}{1-1/5}}= 2(1/5+1/(3\times5^3)+\cdots)$. Take only 2 terms, we get $$\log{\frac{1+1/7}{1-1/7}}\approx 2(1/7+1/(3\times7^3))=0.28766\cdots$$ $$\log{\frac{1+1/5}{1-1/5}}\approx 2(1/5+1/(3\times5^3))=0.40533\cdots$$ so $\log{2}\approx 0.28766+0.40533 = 0.69299$

The actual value is $\log{2}=0.69315\cdots$, so by just taking 2 terms from each expansion, we've already got a relative error of less than $3\times10^{-4}$.

Now, this method can be iterated to even more terms, and in general it would increase the accuracy, but at the price of making the formula more complicated.

Another way to accomplish the goal of achieving rapid convergence is by exploiting number coincidences (these two examples taken from section 7.7 of Introduction to Higher Mathematics by Hua Lo-Keng): $$4\log{2}=\log{\frac{16}{15}} + \log{3} + \log{5}$$ $$2\log{5}=\log{\frac{25}{24}} + 3\log{2} + \log{3}$$ $$4\log{3}=\log{\frac{81}{80}} + 4\log{2} + \log{5}$$ Let $a=\log{\frac{16}{15}}, b=\log{\frac{25}{24}}, c=\log{\frac{81}{80}}$, we get $$\log{2}= 7a+5b+3c, \log{3}= 11a+8b+5c, \log{5}= 16a+12b+7c$$.

Each $a, b, c$ is very close to $0$, so the serial expansion converges rapidly. For example, if we take 2 terms to calculate each of $a, b, c$, then: $$a=\log{(1+\frac{1}{15})}=\log{\frac{16}{15}}\approx 2(1/31+1/(3\times31^3))=0.0645385$$ similarly, $b=0.0408220, c=0.0124225$ then $\log{2}= 7a+5b+3c = 0.6931470$. Relative error is $\leq 3\times10^{-7}$

As a more dramatic example, the following can be used to calculate $\log_{10}{2}$, $\log_{10}{3}$, and $\log_{10}{41}$:

The error analysis can be done by Taylor remainder. For example, $$|\log{\frac{1+x}{1-x}}-2(x+\frac{x^3}{3})|\leq 0.4|\frac{x^5(1+10x^2+5x^4)}{(1-x^2)^5}|$$ So if $|x|<0.3$, then the error is $$|\log{\frac{1+x}{1-x}}-2(x+\frac{x^3}{3})| \leq 1.3|x|^5$$.