hp12c and Kinpo -- perhaps not totally unholy?

[Les Wright]

I am recent owner of a new Kinpo made 12Cp. I was playing around with a pc based emulator of the 12C and was puzzled why it wouldn't return the proper result of a basic compound interest problem from the manual which the calc handled without problem. In the google search, which I have since been unable to replicate, I came across a very long thread in the Forum's archives, 2003 I think, dealing with how the 12Cp at that time would not converge in a timely fashion on the correct interest rate in a fairly basic compound interest problem with a real solution. I have been able to solve the problem without difficulty on my new 12Cp, so I am wondering what has happened to the calculator over the last 3 years.

Does anyone who has been around the Forum for awhile recall the issue of 2003 (sorry I can't seem to find the thread in question)? Is it possible that there has been a substantial ROM bug fix over the last three years, and maybe Kinpo can be thanked rather than denigrated?

Les

[Vieira, Luiz C. (Brazil)]

Hi, Les;

I've been lurking around this forum since 2000, and I read all threads I found about the HP12C Platinum since I started to work on the HP12C Platinum Solutions Handbook.

AFAIK, the first HP12C batch had some bugs, indeed. But after a while, a new HP12C Platinum was introduced, with some new features: parenthesis, back-space while entering numbers and UNDO. The not-seen new feature was a maximum of 80 cash-flow entries against 30 of the first Platinum (and 20, of the original HP12C). Right after that, HP introduced the HP12C Prestige in Brazil, and now the 25th. aniversary eddition. These three 'new' HP12C Platinum seem to be the same calculator with three different outfit. I tested the HP12C Prestige against the new HP12C Platinum (with parenthesis) and they work pretty much the same.

Hope this helps you for now. If there is anything else I did not mention (and probably do not know), others will surely add.

Best regards.

Luiz (Brazil)

[Les Wright]

Thanks Luiz.

One of the things I am learning about such specialized computation devices is that it is imperative to understand at least in general the underlying formulae and algorithms used.

For example, I have developed an interest and understanding discounted cash flow analysis. Used blindly, the NPV functions on the hp12c and in Microsoft Excel yield differing results for the same series of cash flows, whereas IRR is the same.

The reason? The NPV function in Excel assumes the first cash flow occurs one period after time zero. (The practicality of this is dubious, since real life problems almost always involve the outlay of something at time zero.) The help page offers a very simple means of adjusting the computation if the first cashflow (typically the initial investment) occurs at time zero. On the other hand, the hp12c does not make this assumption, and includes the time zero cash flow in the computation of NPV. Once accomodating for this, Excel and hp12c yield identical results. In simplest terms, hp12c NPV = Excel NPv * (1 + i), where i is the desired rate of return per period.

My point is not to give a lecture in financial math--rather, I just wanted to share that had not the functions in question been well documented in both Excel help and the hp12c manual, I would've have gone near glassy-eyed trying to figure this out on my own, with lots of pencil and paper and timelines and whatnot.

I have read some contributors suggest approaching "black box" routines with healthy scepticism, especially if major decisions count on them. I wholly agree.

Les

[Vieira, Luiz C. (Brazil)]

Hi, Les;

first of all, thank you for sharing the results of your tests. This is very interesting. I do not use Excel, but knowing about this difference allow us to discuss the subject with a valid knowledge base. Thanks!

I read my first followup and I see that I did not mention that I tested the newer models and found that they are faster and have no such bugs, at least the ones that were found. I saw that it neither clear stack contents when selecting RPN or Algebraic modes.

Cheers.

Luiz (Brazil)

Edited: 5 June 2006, 12:55 a.m.

[Karl Schneider]

Les --

You might be referring to the following thread from July 2003:

"12c Platinum Perpetuity challenge
" @ http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv013.cgi?read=38855#38855

For the record, I don't believe that the TVM problems that were posed by the original poster were elementary or simple to solve, but the 12C Platinum calc's of the time did not handle them very well.

The first TVM problem (see below) did reveal a slight refinement to the TVM calculation method implemented in the Pioneer-series financial calc's (10B, 14B, 17B/II) over the 12C. This enabled the Pioneers to find the correct solution of FV = -100 for i = 10%/year (simple interest), while the 12C incorrectly returned FV = 0 for the same interest rate.

Quote:

---

If you have an unemployed 12cP, see if it will solve for i for this transaction:

1 pmt/yr (if not using 12C/P)

END mode for payments

f CLEAR FIN

360 n

100 PV

0 FV

10 CHS PMT

i

---

Regards,

-- KS

Edited: 5 June 2006, 2:30 a.m.

[tony (nz)]

Yup that behaviour started with the 18C clamshell in 1986.
With PF=1 and END mode, n=360,i%=10,PV=100,FV=0, solve for PMT, solve for FV, see -100, which is as you say the correct exact solution, if we interpret the other values as exact. Now try PV=144, FV=0, solve for PMT, Solve for FV and see -1000. The 12C still gives 0, which is somewhat closer to -144 than -1000 is. I cannot imagine what coding could give this behaviour, but possibly it is an attempt to make it "look like" an exact or symbolic solution. Reminds me of Casio<G>

I only chose 144 because it is 12*12, but all other values stimulate either zero or a power of ten in the FV, in the neighbourhood of -PV.
I prefer consistency of the 12C.

Cheers,
Tony

Edited: 6 June 2006, 4:45 a.m.

[Karl Schneider]

Tony --

Quote:

---

With PF=1 and END mode, n=360,i%=10,PV=100,FV=0, solve for PMT, solve for FV, see -100, which is as you say the correct exact solution, if we interpret the other values as exact. Now try PV=144, FV=0, solve for PMT, Solve for FV and see -1000. The 12C still gives 0, which is somewhat closer to -144 than -1000 is.

I only chose 144 because it is 12*12, but all other values stimulate either zero or a power of ten in the FV, in the neighbourhood of -PV.

---

Interesting finding! I had not tried other values corresponding to PMT = -PV/i on any Pioneer-series financial, figuring that the code had been refined and that the answer would always be correct.

Quote:

---

Yup that behaviour started with the 18C clamshell in 1986.

---

The 18C/28C were the first calculators to utilize the Saturn processor introduced with the HP-71B. HP took opportunities to improve algorithms to exploit the 64-bit, 12-digit words and faster processor. My favorite example is taking the sine of 3.14159265358 radians -- Pioneer models give the next 12 digits of pi (979323846264x10^-12, the correct answer); pre-Saturn models can accept only 10 input digits (3.141592653), then give only the next two rounded digits (5.9x10^-10) as the answer. But I digress...

From page 207 of the HP-12C manual, the TVM equation (with no odd period) is

(1.) 0 = PV + (1 + iS)PMT*[(1 - (1+i)-N)/i] + FV(1+i)-N    (i not = 0)

With S = 0 for END mode, this simplifies to

(2.) 0 = PV + PMT*[(1 - (1+i)-N)/i] + FV(1+i)-N

Solving for FV,

(3.) FV = -PV/(1+i)-N - PMT*[1 - (1+i)-N)/(i*(1+i)-N)]

Which is what I assumed the 12C/p were using. From your example, with i = 0.1 (10% per period) and N = 360, (1+i)^-N = 1.255x10^-15. Therefore, 1 - (1+i)^-N = 1, within the limits of the calculators (if internal extended precision is not used), and the calculated FV is simply 0 -- the difference of two identical enormous values.

However, the multiplicand to PMT can be separated into two terms and regrouped, yielding the following:

(4.) FV = (-PV - PMT/i)*(1+i)N + PMT/i

Obviously, if (-PV - PMT/i) = 0, then the term (1+i)^N doesn't matter, yielding FV = PMT/i.

In your example, with PV = 100, PMT = -10, and i = 0.1, FV = PMT/i = -PV = -100 is correct.

If (1+i)^N = 1 (as for extremely small i, due to roundoff error), then we get the erroneous result FV = -PV, and no value of payment can be applied.

I suppose that very large values of PMT/i could cause roundoff error in certain situations...

Quote:

---

I prefer consistency of the 12C.

---

I would prefer "consistent correctness" wherever possible, and thought that the Pioneers were indeed using Equation (4.). Apparently, I was mistaken. Only for PV = 100 and PMT = -10 is the correct answer of FV = -100 produced, seemingly by mere coincidence.

Best regards,

-- KS

Edited: 10 June 2006, 9:06 p.m. after one or more responses were posted

[Rodger Rosenbaum]

Hi, Tony,

I notice that the FI function in the PPC ROM gets both examples right. You'd think HP could do as well, wouldn't you?

[tony (nz)]

I wrote...

Quote:

---

I only chose 144 because it is 12*12, but all other values stimulate either zero or a power of ten in the FV, in the neighbourhood of -PV.

---

It is much more curious. With %i=10,PV=144,PMT=-14.4 and putting n=300,301,...360 and solving for FV in each case I see 7 possible answers: 0,-100,-140,-144 (correct),-150,-200 and -1000. Only n=360 gives the -1000, and only n=359 gives the zero. n<=310 seems to be correct (-144).n=311 gives FV=-140 and between there and n=358 the results are bounded by -100 and -200. n=335 gives the first -200.
Surprisingly the 49g+ shows the same behaviour. The HP200LX gives FV=-144 unerringly up to n=400 but then starts showing variability.

Edited: 10 June 2006, 8:15 p.m.

[Karl Schneider]

Hi, Tony --

Well, I'd say that the results are an effect of dropped significant digits in these calculators wihin the limits of their precision for the TVM equation. Results seem to be best on Saturn-based machines (and their direct descendants) when (1 + i)^-N is greater than 10^-12, so that

1 - (1 + i)^N is correctly calculated.

Maybe equation 3) in my post above is being used for the FV calculation.

-- KS

Edited: 10 June 2006, 9:26 p.m.

[tony (nz)]

Hi Karl,

Quote:

---

Maybe equation 3) in my post above is being used for the FV calculation.

---

Yes, quite likely. Probably the best algorithm when solving for FV would be to check if PV+PMT/i=0 (END mode) and then just return FV=-PV, which is correct for all n (positive and negative) - that would avoid an out of range calculation involving n, for example.

Thanks for raising this.

Cheers,
Tony

[Eric Smith]

The 12C Platinum firmware is written by HP, not Kinpo, so all the improvements can be credited to the HP engineers in the calculator division. Said group consists mainly (or perhaps even exclusively) of Cyrille de Brebisson.

As I understand it, Kinpo can be credited (or blamed) for the firmware of the 9s, 9g, and 30s, and for the low-level ARM operating system of the 39g+, 48gii, 49g+, and other ARM-based models.

The 12C Platinum (both firmware versions), 10bII, 17bii+, and 33s firmware is by HP.

Any major improvements in the 12C Platinum firmware were probably introduced in the same firmware release that added parenthesis, backspace, and (partial) undo. This firmware was a substantial redeisgn based on the 17bii+ firmware.

[Gene]

Don't think I believe that. I think Kinpo did the 12cp firmware.

Remember the request for all 12c manuals that were sent to them several years ago? I think they used them to reverse engineer the 12c for the 12cp, and made some mistakes.

[Eric Smith]

Possibly the original 12C Platinum firmware might have been developed by Kinpo.

The firmware of the current 12C Platinum was definitely developed by HP, based on the 17bii+ firmware.

[Gene]

AFAIK, I think that is correct. :-)

See you in San Jose in September!

Any chance we'll see "prototypes" of your new machine?

[Eric Smith]

Quote:

---

Any chance we'll see "prototypes" of your new machine?

---

Yes. In fact, it's fully functional now, thanks mostly to a lot of software effort by Richard Ottosen. I've been too busy with school to work on it very much.

Edited: 6 June 2006, 5:55 p.m.

[Gene]

Ok, let's put it another way...will you have a prototype that might be purchasable at HHC2006? If so, I'll bring my checkbook. :-)

[Eric Smith]

Quote:

---

will you have a prototype that might be purchasable at HHC2006?

---

I'm not certain; I'll talk to Richard Ottosen about that. We've definitely got one extra unit of the old style (the kind that sold on eBay recently). But you probably want the newer style, with the laminated laser-cut case, and I'm not sure whether we'll have any extras of that.

The current status is that it emulates the 21, 22, 25, 27, and almost the 29C (should be working by the conference). It will probably emulate the entire 30 series soon. It does not yet emulate the 41, which is a primary objective. However, the new-style hardware will be firmware upgradeable.

[Eric Smith]

I've discussed this with Richard Ottosen, and it is highly likely that prototype calculators will be available for purchase at the conference. Details such as how many units are avaiable and at what price have not been worked out.

Some will have transparent cases like the one I passed around at the last conference (though at that time it only ran a hardware test program). Some will have black cases. It will be interesting to see which is more popular.

[Jeff O.]

So HHC2006 is to be held in San Jose, California? September 16-17 or 23-24?

Edited: 7 June 2006, 8:09 a.m.

[Jake Schwartz]

> So HHC2006 is to be held in San Jose, California? September 16-17 or 23-24?

The HHC2006 will be Sept 16-17 in San Jose.

Jake Schwartz

[Eric Smith]

Quote:

---

Remember the request for all 12c manuals that were sent to them several years ago? I think they used them to reverse engineer the 12c for the 12cp, and made some mistakes.

---

I think it's more likely that that was done for the Aurora FN1000. If Kinpo was under contract with HP to reengineer the 12C, they would have gotten the manuals from HP, not by begging on the MoHPC forum. And the Aurora FN1000 definitely has far more behavioral quirks than the 12c Platinum, suggesting that the Aurora was designed by engineers with less experience with the 12C (and RPN calculators in general).

I still think that the first 12c Platinum firmware was done in-house by HP, based on a conversation with an HP employee shortly after introduction. But it's something we can ask HP at the upcoming conference.

[Wlodek]

Eric, I believe I talked with the same HP employee, and got the opposite impression - that Kinpo did the first version of the hp12cp themselves. That would have been because the very limited programming effort available within HP at the time was being used for other products. Isn't memory a wonderful thing? ;-)
Wlodek

[Gene]

:-)

[Eric Smith]

Transparent or black?

[db (martinez, ca.)]

Eric;

It's a good thing i had a prior engagement on the Sunday of the 2004 HHC when you talked or i'd have been laying awake nights for two years in anticipation instead of 2 months.

Please bring a clear one for me. I'll bring dead presidents. See you there. - db

Edited: 10 June 2006, 5:39 p.m.

[Gene]

I'll have to think about that.

I think you have my email address, either the hotmail or comcast will work.

If you don't have it, you can find it on my still there website at www.rskey.org/gene

:-)

Gene

[Eric Smith]

You guys do realize that it's only emulating Woodstock and Spice models now, don't you? 41CV and eventually 41CX support is planned, but doesn't yet exist. It will be upgradeable, but I can't absolutely guarantee that upgrade files will actually be provided.

Also, the current hardware (PIC based) is not any faster than the original calculator, and in the case of the 41 will be somewhat slower.

The third generation of hardware will most likely be ARM-based, and should be significantly faster than the original calculators. However, it is unlikely that we will even start development of the new hardware until late in the year or early 2007.

I'm not trying to dissuade you from buying our cool "limited edition" calculators, but I don't want you to misunderstand what it actually is.

[db (martinez, ca.)]

cool ?!?! limited edition ?!?! Now i'm really excited. Makes me want to "buy it now".
Serously; thanks for the clairification. Your calc sounds great as it is. 41 compatability would be gravy.
See you at HHC. I'd like a clear one.

[Ron]

Pardon me for jumping into this thread, the earlier inputs addressed financial equations - one of my specialties. Being late and all, I must have missed some vital info. I use a 49 now but had a 12 something years ago.

I am assuming that the financial calculators now use the natural log minus the 1 in the LNP1 expression located in the fundamental present value equations such as: N*LN(1+I/N) for more accurate results when the number of compounding periods becomes very high. I have used a programmed version of this for years. I admit pursuing these equations satisfies certain curiosities of mine.

Because of this pursuit, I have come to several practical conslusions. Rather than spend so much time getting our math so much more accurate, we should spend more energy getting the forecasting more accurate. In other words, I have been able for years to generate models for cashflow, IRR, etc. that are far more accurate in calculation than represented by the quality of the data you can feed into the model. I can show you models of cashflow that will calculate to the second and penny the present value of such a stream. What's more, they can be fed data about withdrawals and deposits at purely random times of day, dates and any risk factors you want to include and compound the interest anywhere from annual to continuous. They can even accept data streams from amortized projections or individual transactions and key values to any date and time within the domain of the analysis.

Who among us can ever be accurate enough in our projections to ever require that kind of accuracy in computation? Why not just use continuous compounding for everything and transpose results to whatever digital representation we like best. After all, financial decisions are made by decision makers who are in a continuous mode, not digital. We use terms like, "For all practical purposes" to excuse ourselves for not being able to nail down moments and amount of transactions.

Even that great invention of calculus is itself a model of managing errors and estimates. We think we calculate perfection as we inch closer and closer to chaos and turbulence. The gambler who knows business and poker knows that neither is about probabilities, they are about possibilities.

I heard it said several years ago that we should employ only one-arm weather men and economists who would be precluded from using the phrase, "ON THE OTHER HAND..."