@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...
...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