(12C) Base Conversion

08252018, 02:32 PM
Post: #1




(12C) Base Conversion
This program is a slightly shorter version of the 2nd solution that uses the function NPV:
Code: 01  44 13 STO PV Example: 2014_{10} → 3736_{8} 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{xy}{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 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 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{1b}{b} \end{align*}\) That's why we can use the \(\Delta\%\) function to calculate \(i\): Code: 14  45 14 RCL PMT I was a bit surprised that ENTER is needed here: Code: 01  44 13 STO PV 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. 

08252018, 05:28 PM
Post: #2




RE: (12C) Base Conversion
(08252018 02:32 PM)Thomas Klemm Wrote: But it appears that STO PV disables the stack lift. 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 usecases 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? Bob Prosperi 

08252018, 06:38 PM
Post: #3




RE: (12C) Base Conversion
(08252018 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. To claim HP disable financial register stacklift 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  ??? 

08252018, 08:30 PM
Post: #4




RE: (12C) Base Conversion
(08252018 06:38 PM)Albert Chan Wrote: To claim HP disable financial register stacklift 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) 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 HP42S and an HP48G for instance. We are familiar with these differences. On the HP42S you could use: 5 ENTER × 5 ENTER ENTER 1  × On the HP48G you could use: 5 DUP × 5 DUP 1  × or then: 5 ENTER ENTER × 5 ENTER ENTER 1  × Kind regards Thomas 

08252018, 08:38 PM
Post: #5




RE: (12C) Base Conversion
(08252018 06:38 PM)Albert Chan Wrote: My first time beaten by this type of "feature" is with RCL (Yes, it is also documented) This behaviour is completely logical and the way all RPN HPs are supposed to work. Your first example: Code: T 0 0 0 Continue with the second one: Code: T 0 0 0 0 0 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 

08252018, 09:02 PM
Post: #6




RE: (12C) Base Conversion
(08252018 06:38 PM)Albert Chan Wrote:(08252018 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. 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. Bob Prosperi 

08252018, 11:06 PM
Post: #7




RE: (12C) Base Conversion
Thanks all
I had (wrongly) assumed a stored value included the Enter. Example, on my HP12C, 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 

08272018, 08:29 PM
Post: #8




RE: (12C) Base Conversion
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 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)