So, 2^10=1024. That means log10(2)~3/10=0.3. By log laws: 1 - .3 = 0.7 ~ log10(5).
Similarly, log10(3)*9 ~ 4 + log10(2); so, log10(3) ~ .477.
Other prime numbers use similar "easy power rules".
Now, what's log10(80)? It's .3*3 + 1 ~ 1.9. (The real value is 1.903...).
The log10(75) ~ .7*2+.477 = 1.877 (the real answer is 1.875...).
Just knowing some basic "small prime" logs lets you rapidly calculate logs in your head.
Also easy to remember: 7^4 = 2401 ~ 2400. log(2400) = log(3) + 3 log(2) + 2 ~ 19/40 + 3 * 12/40 + 2 = 135/40, so you get log(7) ~ 135/160 = 27/32 = 0.84375.
Direct square: 54^2 = (50 + 4)^2 = 2500 + 2 * 50 * 4 + 4^2.
Direct square-root: 3800 = (61^2=3721) + r ~ (61 + (3800-3721)/(2*61) = 61 + 79/122. To check: (61 + 79/122)^2= 3,800.419. You can estimate the "overhead" by noting that 79/122 ~ 2/3 => (2/3)^2 = 0.444.
Of course, my grandfather would've just used a slide-rule directly.
It's still pretty cool to me that A this works and B it can be used to do so much.
The number of digits minus one is the magnitude (integer). Then add the leading digit like so:
1x = ^0.0
2x = ^0.3 (actually ^0.301...)
pi = ^0.5 (actually ^0.497...)
5x = ^0.7 (actually ^0.699...)
Between these, you can interpolate linearly and it's fine for estimating. Also 3x is close enough to pi to also be considered ^0.5.
In fact, if all you're doing is estimating, you don't even really need to know the above log table. Just use the first digit of the original number as the first digit past the decimal. So like 6000 would be ^3.6 (whereas it's actually ^3.78). It's "wrong" but not that far off if you're using logarithmetic for napkin math.
Looks like 5x=^0.699 means log_10(5)=0.699.
1: 0.0
2: 0.3
3: 0.475
4: 0.6 (2*2)
5: 0.7
6: 0.775 (2*3)
7: 0.85
8: 0.9 (2*2*2)
9: 0.95 (3*3)
So you only need to remember:
2: 0.3
7: 0.85
9: 0.95
1.4 = sqrt(2) -> 0.15
3 = sqrt(9) -> 0.95/2 = 0.475
pi = ~sqrt(10) -> 0.5
4 = 2*2 -> 0.6
5 = 10/2 -> 0.7
6 = 2*3
2pi = 2*sqrt(10) -> 0.3+0.5 = 0.8
8 = 2*2*2 -> 0.9 9: 0.95
Put the effort into remembering a 3 digit log for 7 instead?
Or keep the same precision with ...
7 = ~sqrt(100/2) -> (2-0.3)/2 = 1.7/2 = 0.85
Or even ...
7 = sqrt(sqrt(2401)) = (3*8*100)^(1/4) -> 0.95/8 + 0.3*3/4 + 2/4 = 0.12 + 0.225 + 0.5 = 0.845
Same for 9: sqrt(81) = sqrt(8 * 10) -> (0.3*3 + 1) / 2 = 0.95
At some point it's easier to remember a few numbers than calculate a lot of formulas.
The numbers corresponding approximately to 0 dB, 1 dB, 2 dB, 3 dB etc. (1.0, 1.25, 1.6, 2.0 etc.; more accurate values, like 1.26 or 1.58 instead of 1.25 and 1.6 are typically not needed) are also frequently encountered as such in engineering practice as belonging to various series of standard nominal values, which makes them more useful to have in mind.
Then for any mental computation, it is trivial to convert mentally a given number to the corresponding dB value, perform the computation with additions and subtractions instead of multiplications and divisions, then convert back the dB value to the linear number corresponding to the result.
Doing mental computations in this way, even if it has only about 2 correct digits at most, is enough for debugging various hardware problems, or even for catching software bugs, where frequently an impressive numbers of significant digits is displayed, but the order of magnitude can be completely wrong.
0.0625, 0.125, 0.25, 0.5, 1, 2, 4, 8, 16, 32, (64)
and then multiplying everything by factors of 10 to get it between 0 and 10:
1, 1.25, 1.6, 2, 2.5, 3.2, 4, 5, 6.25 (or 6.4), 8
> log(100)≤log(N)<log(100)
There is a missing 0 in the last log. It should be
> log(100)≤log(N)<log(1000)
Also related: https://blog.timhutt.co.uk/fast-inverse-square-root/
(I see that someone already mentioned fast inverse square root algorithm is related to this, which is famously used by John Carmack which is one of my hero who led me into tech industry, despite I didn't end up in gaming industry)
xeonmc•1d ago