Interesting.
Perhaps it is more practical to use logarithmic formula:
if a=b^n where a, b, n -- integers, a,b>0, then n=ln(a)/ln(b) -- also must be integer number.
But the problem of this approach is a big rounding errors in some cases, so it is necessary to make a direct verification.

(09-07-2018 03:09 AM)Gamo Wrote: This program work ok on HP-12C but so far not work on HP-12C Platinum for Android but HP-12C Platinum on PC work fine.

What wrong with the Android version?

What's wrong with the program?
What exactly does not work on the Android version?
What is your input and what is the output?

You can check this yourself: enter two numbers and use the SST key to step through the program, one line after another. Where exactly does the Android program deviate from the others? Where exactly is the point where the program behaves differently?

Sorry my bad forgot to explain of the problem.
For 12C Platinum on Android I put exactly the same program steps with step numbers like 09 for 12C and 009 for 12C Platinum.
Program run but always return 0 display eventhough
it is true and all the store registers result are correct answer.

(09-07-2018 09:04 AM)Gamo Wrote: Sorry my bad forgot to explain of the problem.
For 12C Platinum on Android I put exactly the same program steps with step numbers like 09 for 12C and 009 for 12C Platinum.
Program run but always return 0 display eventhough
it is true and all the store registers result are correct answer.

Example:
Is 5 to the power of 25

5 ENTER 25 R/S

Display 0 // suppose to be display 1

Correct answer in registers
R1 is 5
R3 is 2
R2 is 25

Remark: 12C Platinum on PC work fine.

Gamo

I can confirm the program as listed in the OP does not produce correct results on HP's HP-12CP Android emulator. I have not tried it on a real 12CP or any other emualtor. Yet.

In the example just above (5,25) the resulting registers (on Android) are:

R1: 5
R2: 25
R3: 3

I don't have time right now to SST through on a real machine side-by-side with the emulator, but will try to do so later today.

Meanwhile, if you have time to look at it Dieter, perhaps the incorrect R3 value above is a hint for where the error lies?

It looks like Gamo found a real bug in the Android emulator. Well done Gamo.

(09-07-2018 02:40 PM)Gamo Wrote: When Y^X loop to 25 at line 017 it keep looping to line 009 one more time to 125 and exit. This suppose to exit exactly on 25 since X is less than or equal to Y conditional test.

(09-07-2018 03:21 PM)rprosperi Wrote: On the 2nd pass through steps 9-17, upon hitting the test in line 17, the stack is:

T: 25
Z: 1
Y: 25
X: 25

On a real 12CP, the test (X<=Y) is true, so execution continues on line 18.

On the Android 12CP, the test (X<=Y) fails, and execution continues on line 19 <==== [ERROR].

OK. Gamo and Bob: please repeat this case (5 and 25) once again and SST through the program until you get to the X≤Y? test in line 17. When this test fails and the next SST continues with the GTO 09 command, press [–] to see the difference between X and Y. Is it zero or something else?

(09-07-2018 08:49 PM)Dieter Wrote: OK. Gamo and Bob: please repeat this case (5 and 25) once again and SST through the program until you get to the X≤Y? test in line 17. When this test fails and the next SST continues with the GTO 09 command, press [–] to see the difference between X and Y. Is it zero or something else?

Actually I thought of that earlier and SST-ed through in FIX-9 mode and confirmed both values were 25.00000000, and it appeared to not be a round-off or loss pf precision issue.

BUT, your idea is clearly better as it actually performs the test under question and revealed the truth, the difference is -6.000000 -E13. (on the emulator)

Update 1: Forgot to mention that this difference is indeed 0.00000000 on the real 12CP.

(09-07-2018 08:49 PM)Dieter Wrote: OK. Gamo and Bob: please repeat this case (5 and 25) once again and SST through the program until
you get to the X≤Y? test in line 17. When this test fails and the next SST continues with the GTO 09 command,
press [–] to see the difference between X and Y. Is it zero or something else?

Just the fact that it failed X≤Y test is enough to deduce X>Y
This is the same as the Microsoft calc bug: sqrt(4) - 2 = -8.1648 ... E-39
Sqrt(X) were using formula Exp(1/2 * ln(X))

For the same reason, android 12C Y^X may be the same way, Exp(X* ln(Y))
Technically, it is not a bug, since 5 ^ 2 = 25.00000000 is indeed 10 digits accurate.

If exact value of Y^X is required (small positive integer X), just build it with multiply (see post 8)

The Y^X function is kind of complicated when use repeatedly in program.
I remember that Dieter mention this many time that when possible use ENTER [x]
is more efficient and Albert Chan also recommended to use ENTER [x] as well.

Remark: Real HP-12C and HP-12C for Android edition is working with [X^Y] loop in program.

Here is the update version specifically for the HP-12C (Platinum) Android edition.

(09-06-2018 07:07 PM)stored Wrote: Perhaps it is more practical to use logarithmic formula:
...
But the problem of this approach is a big rounding errors in some cases, so it is necessary to make a direct verification.

Since the 12CP emulator has roundoff errors anyway, maybe the following approach will work, both on an original 12C and the mis-behaving emulator. The idea is: round the result of ln(n2)/ln(n1) to the nearest integer, then calculate n1^this and check if the result matches n2. As far as I got it, even the 12CP emulator returns powers correctly when rounded to 10 digits. So this should work:

The program sets and exits with FIX 9 mode. If you want to reset this to FIX 2 (or anything else) insert the respective command after the RND in line 20 and before the X=0? test that follows.

EDIT:
Here's an even better version. It returns additional information even if n2 is not an integer power of n1. The stack then holds the closest approximation. Try it and see what you get, e.g. for 5 and 600.