As the title states, I need to be able to calculate logs (base $10$) on paper without a calculator.

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

  • 2
    $\begingroup$ If you can calculate $\log p$ for every prime, you can calculate $\log x$ for every $x \in \mathbb{Q}_+$. $\endgroup$ Jun 4, 2014 at 5:22
  • 1
    $\begingroup$ yes it is base 10. Sorry I didnt mention that. $\endgroup$
    – Ogen
    Jun 4, 2014 at 5:26
  • 2
    $\begingroup$ 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)$. $\endgroup$ Jun 4, 2014 at 5:37
  • 2
    $\begingroup$ And if you don't remember what $\log(2)$ is, remember $2^{10} = 1024 \approx 1000$, therefore $10 \log(2) \approx 3$, or $\log(2) \approx 0.3$. $\endgroup$ Jun 4, 2014 at 6:16
  • 2
    $\begingroup$ If I was going to memorize $\log(2)$, I would use $125 \sim 128$ for this problem. $\endgroup$
    – user14972
    Jun 4, 2014 at 6:27

6 Answers 6


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.

  • 2
    $\begingroup$ Your algorithm is 100% reliable. I gave an answer explaining why ... $\endgroup$
    – String
    Mar 8, 2015 at 21:12
  • 1
    $\begingroup$ 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 $\endgroup$
    – Cameron
    May 24, 2017 at 15:01
  • 4
    $\begingroup$ @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)}$$ $\endgroup$
    – String
    May 26, 2017 at 12:42
  • $\begingroup$ @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. $\endgroup$
    – String
    May 26, 2017 at 12:46
  • 2
    $\begingroup$ 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. $\endgroup$ Jul 4, 2017 at 14:06

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$
  • $\begingroup$ store $d$ as the next digit doesn't mean a string concatenation when $b \neq 10$. $d \times b^{-\text{iteration_index}}$ shall be added for each iteration, where $\text{iteration_index}$ starts with $0$. $\endgroup$
    – ynn
    Aug 25 at 0:52
  • $\begingroup$ This also mean the number of iterations doesn't directly determine the number of accurate digits (i.e. precision) when $b \neq 10$. For example, to calculate $\log _2 3$ with $9$-digit precision, you must iterate at least $30$ times. This is NOT a restriction due to the precision of floating-value calculation; even if you calculate by hand or with arbitrary precision float (i.e. so-called BigFloat), you must iterate $30$ times. Generally speaking, when you want to get $p$-digit precision, you may want to set the number of iterations to a number much larger than $p$ when $b < 10$. $\endgroup$
    – ynn
    Aug 25 at 0:56
  • 1
    $\begingroup$ Here are some sample implementations: (1) Rust with f64 (2) Julia with BigFloat. $\endgroup$
    – ynn
    Aug 25 at 0:58

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.

  • $\begingroup$ 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. $\endgroup$ Jul 4, 2017 at 6:57
  • $\begingroup$ 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. $\endgroup$ Jul 4, 2017 at 7:02

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}$: calculating log(2)

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


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)}$


The algorithm is much older than Ezui: I have a booklet at home (written in dutch) from the 19th century, May 1st 1846, 2nd edition, Delft, NL, written by H. Strootman, lecturer at the Royal Academy in Delft, where the algorithm is explained in gory detail.

Entitled: "Iets over de LOGARITHMEN" in english: "Some about LOGARITHMS" It works for all bases g in e.g. $\log g (X)$ in which case you should not take the nearest power of 10 instead the nearest power of g:

so 10^n becomes $g^n$ ....

It is from what I read in this pocketformat booklet the standard way how people computed logarithms those days ...


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .