jhawk@panix.uucp (John Hawkinson) (05/30/91)
The following question is really one of accuraccy of the HP48SX, specifically,
and the answer might not apply to other calculators:
To compute:
log a
b
You can use:
log a
n
------
log b
n
Therefore, on the 48sx, you must use either:
LOG a LN a
----- or: ----
LOG b LN b
#1 #2
So, my question is this: which is more accurate? #1, or #2? (does the
48 internally use LOG to compute LN, or vice versa?) Thanx.
--
--
John Hawkinson
jhawk@panix.uucptt@jadbalja.jyu.fi (Tapani Tarvainen) (05/31/91)
In article <1991May30.120658.3590@panix.uucp> jhawk@panix.uucp (John Hawkinson) writes: >So, my question is this: which is more accurate? #1, or #2? (does the >48 internally use LOG to compute LN, or vice versa?) Thanx. While I don't really know how it is in the 48, I do know that the HP71B computes LOG (base 10) using LN (although I think it does check for exact powers of ten first), and I've heard (and would be rather surprised if it weren't so) that most of the math routines in the 71 were used in the 48 without changes (not without additions, though :-)), and considering the way logs are computed I'm quite sure they haven't changed this. -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
jurjen@cwi.nl (Jurjen NE Bos) (06/02/91)
jhawk@panix.uucp (John Hawkinson) writes: >The following question is really one of accuraccy of the HP48SX, specifically, >and the answer might not apply to other calculators: No. It is not the accuracy of the HP48, but of the number system it uses: 12 decimal digits. >On the 48sx, you must use either: > LOG a LN a > ----- or: ---- > LOG b LN b > #1 #2 >So, my question is this: which is more accurate? #1, or #2? (does the Both are VERY accurate. The HP48 almost ALWAYS gives the correctly rounded answer to a logarithm; both LN and LOG. >48 internally use LOG to compute LN, or vice versa?) Thanx. Doesn't matter. The internal logarithms are computed to 15 digits, so there is no conversion loss you can see. If the logarithm of a or b happens to fit exactly in 12 digits, one of the two might be marginally more accurate. About other calculators: Don't use them. They do have roundoff in their logarithms :-)
marek@ifi.uio.no (Marek Vokac) (06/03/91)
Re John Hawkinson's question about n-base logarithms on the '48 - I compared the results from LOG/LOG and LN/LN calculations with those produced by Mathematica, and it seems LN is _marginally_ more accurate, the results differed +/- 1 in the last decimal digit calculated. The difference is small enough to be insignificant in most applications; but it does seem to indicate the LN is used for LOG and not the other way round. Marek
jurjen@cwi.nl (Jurjen NE Bos) (06/04/91)
marek@ifi.uio.no (Marek Vokac) writes: >Re John Hawkinson's question about n-base logarithms on the '48 - >I compared the results from LOG/LOG and LN/LN calculations with those >produced by Mathematica, and it seems LN is _marginally_ more >accurate, the results differed +/- 1 in the last decimal digit >calculated. >The difference is small enough to be insignificant in most >applications; but it does seem to indicate the LN is used for LOG and >not the other way round. This is unfortunately not true: As I said in my previous posting, both LN and LOG are based on a 15 digit logarithm function. Roundoff from the conversion is not visible at all on the user level; both functions are almost always correctly rounded to the last decimal. (I think the answers are even *always* correct, but I am not sure; Bill?) My guess is that you used numbers in the range 10..22026 to test your hypothesis. In this range, the precision of the decimal representation of the LOG is slightly less than that of the LN; this effect is known as "wobbling precision". To be exact, numbers that start with a low decimal digit in their mantissa have a smaller relative precision than numbers that start with a high digit. To see this, note that the interval 1.00000000000 .. 1.00000000001 is ten times as big as .999999999999 .. 1.00000000000 (all numbers being twelve digits). I hope this is clear. Remember: The HP48 is much, much more precise than you think; almost all "inaccuracies" are because of its number system, not because of "internal roundoff".
marek@ifi.uio.no (Marek Vokac) (06/05/91)
jurjen@cwi.nl (Jurjen NE Bos) writes: >>Re John Hawkinson's question about n-base logarithms on the '48 - > >>I compared the results from LOG/LOG and LN/LN calculations with those >>produced by Mathematica, and it seems LN is _marginally_ more >>accurate, the results differed +/- 1 in the last decimal digit >>calculated. > >>The difference is small enough to be insignificant in most >>applications; but it does seem to indicate the LN is used for LOG and >>not the other way round. >> >> Marek > >This is unfortunately not true: >As I said in my previous posting, both LN and LOG are based on a 15 digit >logarithm function. Roundoff from the conversion is not visible at all on the >user level; both functions are almost always correctly rounded to the last >decimal. >(I think the answers are even *always* correct, but I am not sure; Bill?) > >My guess is that you used numbers in the range 10..22026 to test your >hypothesis. In this range, the precision of the decimal representation of the >LOG is slightly less than that of the LN; this effect is known as "wobbling >precision". >To be exact, numbers that start with a low decimal digit in their mantissa >have a smaller relative precision than numbers that start with a high digit. >To see this, note that the interval > 1.00000000000 .. 1.00000000001 >is ten times as big as > .999999999999 .. 1.00000000000 >(all numbers being twelve digits). >I hope this is clear. Remember: The HP48 is much, much more precise than you >think; almost all "inaccuracies" are because of its number system, not because >of "internal roundoff". To a certain extent I stand corrected ... BUT: As long as the two approaches (LN/LOG) return _different_ answers, that are visible to the user (and contrary to what you say, the difference is visible; try it), it is interesting to know if there is a consistent tendency for one to be more accurate than the other. Whether internal calculations are to 12, 15 or 100 digits loses some relevancy when only the 12 _visible_ digits are carried over to the next calculation and those digits contain inaccuracies (for whatever reason); any errors _will_ propagate. According to the manual, only a few matrix functions form a special case where full 15-digit accuracy is kept throughout. To test that, try doing 20000 LN 2 LN / 20000 LOG 2 LOG / (notice the difference) then -, the result is not 0. Contrast this to the TI58/59 calculators, which actually used 3 more digits than were visible in _all_ calculations. If you had SQRT(2) in the display, subtracted what you saw and multiplied by 10^3, you'd actually see the remaining digits. Same with PI. Which approach is better is, I would think, largely a philosophical discussion; certainly I prefer HP's way of thinking (what you see is all there is). I _think_ chained calculations on the HP are precise to 12 digits, the evidence supports this belief (with exceptions as stated). What do _you_ believe? BTW, I did some more testing of the HP48 versus Mathematica, and could find no consistent tendency among 100 samples over the range 3 - 100000. The difference was either 0 or 1 in the last _visible_ digit. My theory of LN / LOG dependency is hereby withdrawn. Morale: Yes, the HP48 is precise; that precision has its limits (as with all finite machines), and the logarithm functions are not _always_ correct - of course! Whether you choose to call the reason "roundoff", refer to the number system or whatever is of theoretical interest. As for the logarithms - use whichever suits you. Marek
tt@jadbalja.jyu.fi (Tapani Tarvainen) (06/05/91)
In article <3630@charon.cwi.nl> jurjen@cwi.nl (Jurjen NE Bos) writes: >marek@ifi.uio.no (Marek Vokac) writes: >>I compared the results from LOG/LOG and LN/LN calculations with those >>produced by Mathematica, and it seems LN is _marginally_ more >>accurate, the results differed +/- 1 in the last decimal digit >>calculated. >>The difference is small enough to be insignificant in most >>applications; but it does seem to indicate the LN is used for LOG and >>not the other way round. >This is unfortunately not true: >As I said in my previous posting, both LN and LOG are based on a 15 digit >logarithm function. Roundoff from the conversion is not visible at all on the >user level; both functions are almost always correctly rounded to the last >decimal. >(I think the answers are even *always* correct, but I am not sure; Bill?) What isn't true? That LN is used for LOG or that LN/LN is more accurate than LOG/LOG? I'm fairly sure that LN is used in computing LOG (because it's easier and because that's the way HP71B does) -- but without rounding the intermediate result, i.e., it computes LN with 15 digits, divides that with 15-digit LN(10), and rounds only then. Consequently the difference in accuracy between LN and LOG is negligible for all practical purposes, but if there is a difference, LN is better. Considering how the LN is computed, I'd guess the result is not quite always correctly rounded, but quite likely the error is always less than 0.51 units in the least significant digit or something like that. And since there is one extra step in LOG, it would be slightly less accurate (maybe as much off as 0.52 units in LSD!?). (Might be fun to figure out the maximum errors exactly. Perhaps someone at HP already has?) However, even if both LN and LOG were always correctly rounded, LN/LN and LOG/LOG would still occasionally give inaccurate results (well, at least incorrectly rounded). And in worst case analysis the small difference in accuracy would be doubled (although in the average it would probably vanish). This could explain the results as compared to Mathematica. (The "wobbling precision" effect is also possible, but note that it can work either way, depending on the range of numbers used.) (A side note: F1 and F2 being equally accurate would not automatically imply that F3 could be computed using either with equally good results, although in this case it apparently is so. Consider, e.g., computing hyperbolics or compound interest with LN and EXP or with LNP1 and EXPM.) At this point I should stress that the differences I've been talking about are so small that even detecting them is hard, let alone finding a case where they matter in practice. Nonetheless I'd recommend LN/LN over LOG/LOG, but mainly for another reason: it is faster. (Prediction based on the theory that LOG is computed with LN -- and confirmed by an experiment I just did: the difference is some 2 ms per log.) -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
grue@cs.uq.oz.au (Frobozz) (06/06/91)
hiya,
This stream seems to be never ending .... :-)
My little bit is a routine that calculates log to any base using
the full 15 digit internal precision. The routine checks its arguments and
it only works when given 2 real numbers (unlike the built in log functions
which also accept complex numbers and symbolics).
To use this program enter the base into level 2 of the stack and the
number you want the log of on level 1 and run the program.
e.g. Log 3 base 2, would be calculated as:
2 ENTER 3 LOGB [ I call the program LOGB ]
Here it is (nice and short): [ ASC format ]
"D9D20FDE8199040D9D201C5A2B5BA2322301C5A2B5BA28E9A20B5A2B2130B213
0DFF8"
Pauli
seeya
Paul Dale | Internet/CSnet: grue@cs.uq.oz.au
Dept of Computer Science| Bitnet: grue%cs.uq.oz.au@uunet.uu.net
Uni of Qld | JANET: grue%cs.uq.oz.au@uk.ac.ukc
Australia, 4072 | EAN: grue@cs.uq.oz
| UUCP: uunet!munnari!cs.uq.oz!grue
f4e6g4Qh4++ | JUNET: grue@cs.uq.oz.au
--tt@jadbalja.jyu.fi (Tapani Tarvainen) (06/06/91)
In article <CMM.0.90.2.676118190.marek@nikud.ifi.uio.no> Marek Vokac <marek@ifi.uio.no> writes: >I _think_ chained calculations on the HP are precise to 12 digits You are definitely correct -- as far as normal user-level language is concerned. In "system RPL" I expect it would be easy to use extended precision all the time and round only when it suits you. It might also be possibly to use the Extended type in user RPL, by replacing normal function calls with calls to the internal, non-rounding routines (via SYSEVAL maybe, else with short machine code). >Morale: Yes, the HP48 is precise; that precision has its limits (as >with all finite machines), and the logarithm functions are not >_always_ correct - of course! But they could be always _correctly rounded_ (even though I don't think they are). The basic arithmetic funtions have been that way since the HP41, I believe (but weren't in the 67/97). (My memory is a bit vague here, don't take my word for it.) -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)