I'm trying to make a Log or Antilog table small enough to fit in the back of a wallet calendar (or a business card). My intend is to build a mathematically useful gift that can be used by anybody eager to spend 5 minutes learning how it works.
To simplify the question let's assume that I'm able to fit just 50 numbers in the table (with some spare space to add some useful logarithmic formulas and some additional constants like $\log_{10}(2)$, $\log_{10}(e)$ or $\log_{10}(\pi)$).
My question is: What 50 numbers should I select to maximize the usefulness of the table?
My first idea is to select the decimal logarithms of the first 50 even numbers:
x | Log(x)
--------------
2 | log(2)
4 | log(4)
... | ...
100 | log(100)
But it turns out that the first 5 logarithms are not necessary at all since: log(x) = log(10·x)-1.
I can put them in the table anyway or just use 45 numbers (which are both sub-optimal options from my point of view) or simply re-scale the whole table:
x | Log(x)
------------------
11.8 | log(11.8)
13.6 | log(13.6)
... | ...
100.0 | log(100.0)
But if I'm not going to be able to obtain the logarithm of most natural numbers maybe it is a better idea to just make an Antilog table:
x | AntiLog(x)
---------------------
0.00 | antilog(0.00)
0.02 | antilog(0.02)
... | ...
0.98 | antilog(0.98)
I know that both kind of tables (logarithmic or antilogarithmic) can be used to compute logarithms and antilogarithms approximately (using a direct or a reverse look-up depending on the case) but I'm not sure if there is a good reason to prefer the former ones instead of the latter ones.
One possible argument in favor of logarithmic tables is that they can be used to compute the logarithm of a very big number as long as this number has small factors since log(a·b) = log(a)+log(b). With an antilogarithmic table you can only approximate the logarithm of a prime number and, therefore, you will only obtain an approximate answer (since the logarithms are irrationals in general, here approximate should be read as with less precision than the numbers in the table offer).
Are there more arguments in favor of logarithmic tables (versus antilogarithmic tables)?
Are them strong enough to justify the waste of the 10% of the table?
Are there some applications where each type of table is preferred over the other?
Is one operation used more often than the other in practice?
Assuming that both operations are equally likely to be used, and that a direct look-up provide better precision than a reverse look-up, which operation should I privilege? Are the interpolation errors equally severe in both cases?
Related Questions:
Since the precision on the left column of the table is just 1/50 (in the sense that we are going to divide either [1,100] or [0, 1) into 50 equidistant points), I'm not sure about how much precision should I use in the right column. Does it make sense to fit as many decimal places as possible or is it just a waste of ink and readability?
Can you suggest a better content for a table like this? For example, following a previous argument it may be better to make a table of the logarithms of the first 50 prime numbers (finding a logarithm will be slightly more difficult and that's OK but I'm not sure if that kind table will allow me to find antilogarithms or arbitrary numbers with a reasonable precision). A good trade off may be to list the logarithms of the first 50 odd numbers (instead of the first 50 even numbers) to include all prime numbers smaller than 100.
Which formulas and constants would you add to increase the usefulness of the gift? (remember that the space is really limited)
Example:
This is an example of what I mean by Decimal Logarithms Table in a Business Card:
No comments:
Post a Comment