(12C) Base Conversion

[Thomas Klemm]

This program is a slightly shorter version of the 2nd solution that uses the function NPV:

Code:

01 -    44 13  STO PV
02 -       36  ENTER
03 -    45 15  RCL FV
04 -       10  ÷
05 -    43 25  INTG
06 -    43 13  CFo
07 -    45 15  RCL FV
08 -       10  ÷
09 -    43 25  INTG
10 -    43 35  x=0
11 - 43,33 14  GTO 14
12 -    43 14  CFj
13 - 43,33 07  GTO 07
14 -    45 14  RCL PMT
15 -        1  1
16 -       24  Δ%
17 -    44 12  STO i
18 -    45 13  RCL PV
19 -    42 13  NPV
20 -    45 14  RCL PMT
21 -    45 15  RCL FV
22 -       30  −
23 -       20  ×
24 -       40  +

Example: 2014₁₀ → 3736₈
10 STO PMT
8 STO FV
2014 R/S

Formulas Used

Net Present Value

NPV = net present value of a discounted cash flow.
CF_j = cash flow at period j.

\(NPV=CF_0+\frac{CF_1}{(1+i)^1}+\frac{CF_2}{(1+i)^2}+\cdots+\frac{CF_n}{(1+i)^n}​\)

Percentage

\(\Delta\%=100\ \frac{x-y}{y}\)

Explanation

We can calculate the remainders by dividing the number continuously by the base we want to transform to (here stored in FV):

Code:

2014 ÷ 8 = 251  →  6 = 2014 - 8 × 251
 251 ÷ 8 =  31  →  3 =  251 - 8 ×  31
  31 ÷ 8 =   3  →  7 =   31 - 8 ×   3
   3 ÷ 8 =   0  →  3 =    3 - 8 ×   0

These remainders have to be multiplied by powers of the base we transform from (here stored in PMT):

Code:

   6 = 1 × 2014 - 8 × 1 ×  251
  30 = 10 × 251 - 8 × 10 ×  31
 700 = 100 × 31 - 8 × 100 ×  3
3000 = 1000 × 3 - 8 × 1000 × 0

And then when we add up all the terms we get:

Code:

3736 = 2014 + 2 × (251 + 10 × 31 + 100 × 3)

To calculate the polynomial we use NPV.

For this to work we have to solve for \(i\) in:

\(1+\frac{i}{100}=\frac{1}{b}\)

where \(b\) is the base we transform from.

Thus

\(\begin{align*}
i &= 100\ (\frac{1}{b}-1)\\
&= 100\ \frac{1-b}{b}
\end{align*}\)

That's why we can use the \(\Delta\%\) function to calculate \(i\):

Code:

14 -    45 14  RCL PMT
15 -        1  1
16 -       24  Δ%
17 -    44 12  STO i

I was a bit surprised that ENTER is needed here:

Code:

01 -    44 13  STO PV
02 -       36  ENTER
03 -    45 15  RCL FV

But it appears that STO PV disables the stack lift.

From the manual:

Quote:In addition, the stack does not lift when a number is entered if the last operation performed was storing a number into a financial register.

[rprosperi]

(08-25-2018 02:32 PM)Thomas Klemm Wrote:  But it appears that STO PV disables the stack lift.

From the manual:

Quote:In addition, the stack does not lift when a number is entered if the last operation performed was storing a number into a financial register.

Although not immediately intuitive, after a bit of thought it does make sense; since the value just stored is preserved and available, there is no need to push it onto the stack (and possibly push something off the top), it is simply replaced by the next value entered.

This is the subtle kind of feature where HP really excelled, IMHO. Although no doubt initially designed to enable stack lift, for symmetry with most other commands, real use-cases likely showed it wasn't necessary most of the time, so they changed to not enable stack lift, thus preserving as much stack as possible.

Best of all, they documented it.

Oddly, the same is not true with generic register storage; it seems the same logic would hold in these cases too. Anyone have a suggestion why these behaviors would be different?

[Albert Chan]

(08-25-2018 05:28 PM)rprosperi Wrote:  Oddly, the same is not true with generic register storage; it seems the same logic would hold in these cases too.
Anyone have a suggestion why these behaviors would be different?

To claim HP disable financial register stack-lift on purpose is a bit weak.
This could explain away almost anything, even above odd behavior
(real use cases suggest ... it is documented ... uh, it is a feature)

Sadly, by claiming bug as feature, it will never get fixed.

My first time beaten by this type of "feature" is with RCL (Yes, it is also documented)
Say, 5 is stored in memory 0, with a clear stack:

5 * 5: RCL 0 Enter x => 25 -- so far so good
5 * 4: RCL 0 Enter 1 - x => 100 -- ???

[Thomas Klemm]

(08-25-2018 06:38 PM)Albert Chan Wrote:  To claim HP disable financial register stack-lift on purpose is a bit weak.

There are other cases where this is the case (e.g. ∑+ and ∑-) and this behaviour makes sense.
Since it's documented it's definitely not a bug.
Compare this with the CHS and Stack Lift bug:

Quote:However, I have discovered that CHS only seems to enable stack lift on the 11C and 34C when the operand in the X register is not zero.

Quote:My first time beaten by this type of "feature" is with RCL (Yes, it is also documented)
Say, 5 is stored in memory 0, with a clear stack:

5 * 5: RCL 0 Enter x => 25 -- so far so good
5 * 4: RCL 0 Enter 1 - x => 100 -- ???

This has nothing to do with RCL 0. You get the same result if you just enter 5 instead. This is exactly the difference between ENTER on an HP-42S and an HP-48G for instance. We are familiar with these differences.

On the HP-42S you could use:

5 ENTER ×
5 ENTER ENTER 1 - ×

On the HP-48G you could use:

5 DUP ×
5 DUP 1 - ×

or then:

5 ENTER ENTER ×
5 ENTER ENTER 1 - ×

Kind regards
Thomas

[Dieter]

(08-25-2018 06:38 PM)Albert Chan Wrote:  My first time beaten by this type of "feature" is with RCL (Yes, it is also documented)
Say, 5 is stored in memory 0, with a clear stack:

5 * 5: RCL 0 Enter x => 25 -- so far so good
5 * 4: RCL 0 Enter 1 - x => 100 -- ???

This behaviour is completely logical and the way all RPN HPs are supposed to work.

Your first example:

Code:

T    0     0     0
Z    0     0     0
Y    0     5     0
X    5     5    25

   RCL 0  ENTER  x

Continue with the second one:

Code:

T    0     0     0     0    0
Z    0    25    25     0    0
Y   25     5     5    25    0
X    5     5     1     4  100

   RCL 0  ENTER  1     -    x

You see that the "1" overwrites X because ENTER disables the stack lift.
Add a second ENTER and it will work as you have intended.

On the other hand in the first example ENTER is directly followed by the multiplication, so X and Y are multiplied and you get x².

I think it is fine this way.

Dieter

[rprosperi]

(08-25-2018 06:38 PM)Albert Chan Wrote:  

(08-25-2018 05:28 PM)rprosperi Wrote:  Oddly, the same is not true with generic register storage; it seems the same logic would hold in these cases too.
Anyone have a suggestion why these behaviors would be different?

To claim HP disable financial register stack-lift on purpose is a bit weak.
This could explain away almost anything, even above odd behavior
(real use cases suggest ... it is documented ... uh, it is a feature)

Sadly, by claiming bug as feature, it will never get fixed.

My first time beaten by this type of "feature" is with RCL (Yes, it is also documented)
Say, 5 is stored in memory 0, with a clear stack:

5 * 5: RCL 0 Enter x => 25 -- so far so good
5 * 4: RCL 0 Enter 1 - x => 100 -- ???

Uh... no.

Although there are indeed bugs in every calculator (HP included) this is clearly not the case here; Thomas and Dieter's detailed comments explain similar cases as well.

Bottom line is both RPN and RPL require extensive use to really grasp. The subtle reason this was changed here (after storing the 12C Financial Values/Registers) is almost certainly as explained in my post above; since it does not occur upon storing normal registers (as is the case on all other machines), it's clear this was deliberately changed for the financial registers.

[Albert Chan]

Thanks all

I had (wrongly) assumed a stored value included the Enter.
Example, on my HP-12C, RCL 0 RCL 0 will set X = Y = 5

There is no need to do RCL 0 Enter RCL 0

So, the extra Enter must do something ... I should read the manual

[Thomas Klemm]

This is related to OEIS A014263: Integers with Exclusively Even Digits.

Quote:Integers written in base 5 and then doubled (in base 10).

Example:

10
PMT
5
FV

153
R/S
2
x

2,206.00