2 views

Skip to first unread message

Dec 4, 2002, 12:14:54 PM12/4/02

to

This article explores the question, "In RPL, what is the best method for

finding logs to arbitrary bases?"

finding logs to arbitrary bases?"

Definitions:

ULP = "Unit in the Last Place". Example: 1.33333333334 is one ULP more

than 1.333333333333 in a 12-digit calculator.

LOG(Y,X) = log of Y, base X.

To find LOG(Y,X), six methods have been suggested here. All are

*mathematically* equal, but they give UNEQUAL RESULTS when implemented in

RPL due to error accumulation. All assume Y on level 2 and X on level 1.

The Six Methods are:

(1) LN SWAP LN SWAP /

(2) LOG SWAP LOG SWAP /

(3) LN XROOT LN

(4) LOG XROOT LOG

(5) Method #1 in System RPL

(6) Method #3 in System RPL

Method #1 often gets different results from Method #2. Examples:

LOG(12,2): Method #1 is right; Method #2 is wrong.

LOG(13,2): Method #1 is wrong; Method #2 is right.

LOG(17,2): Both #1 and #2 are one ULP high.

LOG(21,2): Both #1 and #2 are one ULP low.

LOG(18,2): #1 is one ULP high; #2 is one ULP low.

LOG(37,2): #1 is one ULP low; #2 is one ULP high.

Therefore it cannot be said that #1 or #2 is *always* better than the other.

Which of the two is more often accurate? Furthermore (and possibly

differently), which of the two has the greater standard deviation from the

correct answer?

Taking the log of RAND base RAND one thousand times is interesting; it seems

to support the counterintuitive Method #2. Is that because RAND is always

between 0 and 1, for which LNP1 is more accurate than LN? I do not know.

This would suggest that System RPL versions of Methods #2 and #4 should be

tested, which as far as I know has not been done.

Methods #3 and #4 are occasionally more accurate than Methods #1 and #2, and

benefit from being short and easy to perform from the keyboard. However,

Methods #3 and #4 are *usually* less accurate than Methods #1 and #2, so

don't use 'em in a program or when you need the greatest possible accuracy.

Method #5 can be coded thus:

::

CK2NOLASTWD

CK&DISPATCH1

REALREAL

::

2%>%%

%%LN

SWAP

%%LN

SWAP

%%/>%

;

;

and Method #6 looks similar:

::

CK2NOLASTWD

CK&DISPATCH1

REALREAL

::

2%>%%

%%LN

%%1/

%%^

%%LN

%%/>%

;

;

Method #5 is so accurate that I've been unable to find a case where it gets

the wrong answer, although there *must* be some such cases, since RPL

*truncates* results after the 15th digit and then *rounds* to the 12th

digit. So I'll guess that one out of every 2000 random results from Method

#5 will be off by one ULP. But that's just a guess.

Method #6 is very accurate too, but slightly less than Method #5. Example:

LOG(2,23):

Method #1 --> .221064729457

Method #2 --> .221064729457

Method #3 --> .221064729461

Method #4 --> .221064729456

Method #5 --> .221064729458 <-- correct

Method #6 --> .221064729457

Bottom line: Use Method #5 when you need results that are good to the last

ULP.

Credit: All results were verified using BIGCALC, an old but blazingly fast

DOS RPN calculator with settable precision to over 1000 digits. BIGCALC was

written by Judson McClendon.

-Joe-

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu