(12C) Y^X for Large Numbers

[Gamo]

Compute large Y^X
Either on Large Y or Large X
Answer as Y EEX X

Example:
110^125
110 ENTER 125 R/S > 1.4931 R/S > 255 same as 1.4931 x 10^255

Code:


X<>Y
LN
x
10
LN
STO 1
÷
ENTER
ENTER
ENTER
.5
-
EEX 9
+
EEX 9
-
ENTER
Roll Down
-
RCL 1
x
e^x
R/S
Roll Down
Roll Down
GTO 00

Gamo

[Carsen]

This is a neat program. I like it.

I found that you could use the LSTX command instead of another EEX 9. That would save 1 program line.
So it would be...

[EEX] 9
+
LSTX
-

[Carsen]

This was pretty interesting so I wrote my own program. Here's what I got...

Code:


01  SWAP
02  g  LN
03  1
04  0
05  g  LN
06  ÷
07  x
08  g  INTG
09  g  LSTX
10  g  FRAC
11  1
12  0
13  SWAP
14  y^x

When you get the results, the mantissa is in the x-register and the exponent is in the y-register. For example(s)...
110 [ENTER] 125 [R/S] --> 1.493088670 (the mantissa) [SWAP] 255 (the exponent)
2 [ENTER] -7000 [R/S] --> 0.616637596 (the mantissa [SWAP] -2107 (the exponent)

[Gamo]

Thank You Carsen
Your program is a lot shorter and simple to use.
Just by using SWAP for EEX

Gamo

[Dieter]

@Gamo: please forgive me, but I simply have to ask:

Why did you choose such a complicated method to get the integer part of X...

Code:

.5
-
EEX 9
+
EEX 9
-

...and then the fractional part...

Code:

ENTER
Roll Down
-

...instead of the simple INTG and FRAC command that are readily available ?-)

It's essentially the use of these commands that makes Carsen's program so much shorter.

@Carsen: but it gets even one step shorter. ;-)

Code:

01 X<>Y
02 LN
03 x
04 1
05 0
06 LN
07 /
08 INTG
09 1
10 0
11 LstX
12 FRAC
13 y^x

BTW, the accuracy of the result is limited. It can be shown that the number of valid significant digits (i.e. of the mantissa) is reduced by the number of digits in the exponent (or even one more). This means, if the exponent has 4 digits you should not trust not more than 6 or even 5 digits of the mantissa.

Example: For 110^125 the program returns 1,493089014 E+255 (my version) or 1,493088670 E+255 (your version). The difference in the last digits is due to merely 1 ULP change during the log10 calculation. Now the three digits of the exponent (255) reduce the mantissa accuracy from 10 to only 7 digits, i.e. 1,493089 E+255. And indeed the true result is 1,493088824218...E+255. Likewise 2^–2003 is calculated as 9,185049476 E+602 while it actually is 9,185045562 E+602. Since the exponent has 3 digits the mantissa loses at least 3, here even 4 digits and 9,18505 E+602 is all you get.

In the same way the result of 2^–7000 cannot be trusted in more than 6 digits, i.e. 0,616638 E–2107.

Finally here's a deluxe version that also adjusts the mantissa for negative exponents, i.e. for the last example it will return 6,16638 E–2108:

Code:

01 X<>Y
02 LN
03 x
04 1
05 0
06 LN
07 /
08 ENTER
09 FRAC
10 0
11 x≤y?
12 GTO 16
13 e^x
14 +
15 ENTER
16 R↓
17 -
18 1
19 0
20 LstX
21 y^x

;-)

Dieter

[Carsen]

One step shorter? Wow! Thanks Dieter. That's amazing to me because I thought it couldn't get any shorter.

And I realized the error that this program produces but I didn't think it was in correlation to the amount of digits with the exponent. I have a question though. Does this error come from the 12C being unable to hold as many decimal places (internally and externally) because of how big the integer is?

[Dieter]

(01-30-2018 06:03 PM)Carsen Wrote:  And I realized the error that this program produces but I didn't think it was in correlation to the amount of digits with the exponent. I have a question though. Does this error come from the 12C being unable to hold as many decimal places (internally and externally) because of how big the integer is?

It's quite simple. The program calulates the base-10 log of the desired power. This can be split into an integer part and an fractional part. For 110^125 this log is 255,1740857. So the result is 10^255 * 10^0,1740857 = 10^255 * 1,493...

Since the exponent 255 occupies three digits there are only seven digits left for the fractional part from which the mantissa is calculated. And since there always is a potential error of 1 unit in the last place (compare the results of your and my program) the mantissa can be off by a factor of 10^1E–7 = 1,000000023 (≈1+ln10·1E–7) which means a relative error of 2,3E–7. This is equivalent to an absolute error between 1*2,3E–7 and 9,999...*2,3E–7 = 2,3E–6 by which the mantissa can be off. This again means six or five valid decimals, or seven or six significant digits.

Try it: The calculated base-10 log of 120^555 is 1153,945591. The actual value is 1153,9455915564... so the log here even is almost correct to 10 digits. But 10^0,945591 is 8,822486450 while only 10^0,9455915564 yields the correct mantissa 8,822497753. The calculated result is only correct to five significant digits: 8,8225.

So the reason for the limited accuracy is simply the number of remaining digits for the fractional part from which the mantissa is calculated. The more digits the integer part (= exponent) has the less remain for the fractional part, i.e. for the mantissa.

Rule of thumb: if the exponent has n digits you should view the mantissa in FIX 9–n (if the mantissa is ≤ 2) or even in FIX 8–n (if it is larger). This limits the error to 1 unit in the last displayed digit. For the last example (8,822...E+1153) this means FIX 8–4 = FIX 4. Likewise the result of the first example 110^125 = 1,493...E+255 can be viewed in FIX 9–3 = FIX 6.

Dieter

[Gamo]

Hello Dieter

Thank You for correcting this program complication.

I though that by using EEX9 this will help increase accuracy but I proved wrong.

Gamo