## Calc 12E: TVM zero-payment bug

### Calc 12E: TVM zero-payment bug

See the latest App Store review (one star, posted by "e..."). That's not my review but the reviewer did find a serious error in the TVM function.

The reviewer set up the problem n = 7.6, PV = -62, PMT = 0, FV = 15. Calc 12E produced the result 99.81, which is obviously incorrect, and an HP 12C produced the result -17.033, which is correct.

You can verify this by calculating ((1 - 0.17033) ^ 7.6) * 62 ... the result is 14.999.

Other values for n, PV, PMT and FV also give incorrect answers. For example: n = 1, PV = 1, PMT = 0, FV = -1 produces i = 100. The correct answer should be i = 0.

The common thread may be TVM calculations where PMT is set to 0 and you are solving for i.

There are other scenarios that do give the correct answer:

n = 1, PV = 1, PMT = 0, FV = -1.5 produces i = 50

n = 1, PV = 1, PMT = 0, FV = -2 produces i = 100

I love this app, but please squash this bug ASAP!

The reviewer set up the problem n = 7.6, PV = -62, PMT = 0, FV = 15. Calc 12E produced the result 99.81, which is obviously incorrect, and an HP 12C produced the result -17.033, which is correct.

You can verify this by calculating ((1 - 0.17033) ^ 7.6) * 62 ... the result is 14.999.

Other values for n, PV, PMT and FV also give incorrect answers. For example: n = 1, PV = 1, PMT = 0, FV = -1 produces i = 100. The correct answer should be i = 0.

The common thread may be TVM calculations where PMT is set to 0 and you are solving for i.

There are other scenarios that do give the correct answer:

n = 1, PV = 1, PMT = 0, FV = -1.5 produces i = 50

n = 1, PV = 1, PMT = 0, FV = -2 produces i = 100

I love this app, but please squash this bug ASAP!

### Re: Calc 12E: TVM zero-payment bug

I can not see e...'s review in the store?

I tested it as well (curiosity, idleness ) and found two preconditions (rather than one) for the bug to manifest itself. It requires both PMT = 0 and PV >= FV (absolute values of course). If either of these conditions is not satisfied then it appears the correct answer is given. I have compared only a sample of those testing results with a real HP but the major errors are obvious when they appear.

By way of further explanation:

Edit: After posting I looked back at HP User's additional incorrect and correct examples and they satisfy my criteria above. Like HP User, I look forward to a rapid bug fix

I tested it as well (curiosity, idleness ) and found two preconditions (rather than one) for the bug to manifest itself. It requires both PMT = 0 and PV >= FV (absolute values of course). If either of these conditions is not satisfied then it appears the correct answer is given. I have compared only a sample of those testing results with a real HP but the major errors are obvious when they appear.

By way of further explanation:

- If PMT = 0 and you substitute 62.1 or more, rather than 62 or any smaller number in FV, then it works.

If PMT <> 0, then PMT may be positive or negative and it still works regardless of PV and FV.

Edit: After posting I looked back at HP User's additional incorrect and correct examples and they satisfy my criteria above. Like HP User, I look forward to a rapid bug fix

### Re: Calc 12E: TVM zero-payment bug

on the way.

(@$*&!#$)

Kim

(@$*&!#$)

Kim

### Re: Calc 12E: TVM zero-payment bug

Fixed and uploaded... you should see an update in the next few days.

For those that want to know, the problem was the addition (in 1.1.0) of a check for exceptionally small interest rate problems, normally one wouldn't ever see these but we are to be able to handle femto-percent interest rates so we can support continuous compounding properly and tiny interest rates require different math because of the precision limitations in computing devices. In that check process, I was looking for values smaller than 1e-8 in which case the algorithm would calculate the answer differently... but I blew it and didn't account for signs in an internal intermediate variable and wrongly "chose" the small interest rate when the interest rate was in fact suitable to "standard" computational means.

I'm terribly sorry about this, it got past my QA routine because (ahem, cough, cough, choke) the QA routine was also modified to test the small interest rate case and didn't check the "normal" interest rate stuff. QA dood has been summarily flogged and owes me 1000 pushups when he gets back from the 160 hours of community service I sentenced him to. He's picking up trash on the side of the road, then will be ringing the bells at the kettle outside the Gucci store in Two Dot, Montana. I figure the pushups will take him another month, he's a computer junkie with really skinny arms.

Kim

For those that want to know, the problem was the addition (in 1.1.0) of a check for exceptionally small interest rate problems, normally one wouldn't ever see these but we are to be able to handle femto-percent interest rates so we can support continuous compounding properly and tiny interest rates require different math because of the precision limitations in computing devices. In that check process, I was looking for values smaller than 1e-8 in which case the algorithm would calculate the answer differently... but I blew it and didn't account for signs in an internal intermediate variable and wrongly "chose" the small interest rate when the interest rate was in fact suitable to "standard" computational means.

I'm terribly sorry about this, it got past my QA routine because (ahem, cough, cough, choke) the QA routine was also modified to test the small interest rate case and didn't check the "normal" interest rate stuff. QA dood has been summarily flogged and owes me 1000 pushups when he gets back from the 160 hours of community service I sentenced him to. He's picking up trash on the side of the road, then will be ringing the bells at the kettle outside the Gucci store in Two Dot, Montana. I figure the pushups will take him another month, he's a computer junkie with really skinny arms.

Kim

### Re: Calc 12E: TVM zero-payment bug

Quis custodiat ipsos custodes?

Good to hear it is fixed.

Good to hear it is fixed.

### Re: Calc 12E: TVM zero-payment bug

I must add my 2 cents here. I ran these numbers through Ernest Brock's 10bii calculator and the answer was -17.03253 ....... right on the money and only $4.95. I guess this is one case where you don't get what you pay for. I really don't understand, stonemeadow is claiming they have one of the only really accurate calculators on the market, yet Ernie Brock has not failed with any of the "so-called" problem calculations so far. And, Ernie's calculator is $20 less than 12E. I guess my question is "Where's the beef"

HP user wrote:See the latest App Store review (one star, posted by "e..."). That's not my review but the reviewer did find a serious error in the TVM function.

The reviewer set up the problem n = 7.6, PV = -62, PMT = 0, FV = 15. Calc 12E produced the result 99.81, which is obviously incorrect, and an HP 12C produced the result -17.033, which is correct.

You can verify this by calculating ((1 - 0.17033) ^ 7.6) * 62 ... the result is 14.999.

Other values for n, PV, PMT and FV also give incorrect answers. For example: n = 1, PV = 1, PMT = 0, FV = -1 produces i = 100. The correct answer should be i = 0.

The common thread may be TVM calculations where PMT is set to 0 and you are solving for i.

There are other scenarios that do give the correct answer:

n = 1, PV = 1, PMT = 0, FV = -1.5 produces i = 50

n = 1, PV = 1, PMT = 0, FV = -2 produces i = 100

I love this app, but please squash this bug ASAP!

### Re: Calc 12E: TVM zero-payment bug

Yes he has. See my final post in your thread about bringing the price down to $14, where I tested a series of calculations on a variety of available calculators, sayingtsinvest wrote:Ernie Brock has not failed with any of the "so-called" problem calculations so far.

xeno wrote:So, ... Brock's code offered you the opportunity to accept a solution with no warning that two other valid solutions existed. Indeed, the one that neither [calculator] gave ... may well be the best one. Is that not a problem?

In that test I used his financial code in allRPNcalc rather than the 10Bii. I invite you to discover whether my assumption that the code base is the same is correct. The problem again (the extra thousands do not matter) was:

-180

100 [5]

-100 [5]

0 [9]

200

IRR

If you get any of the answers 1.86, 14.35 or 29.02 then the arithmetic is wonderful and the user is right up the garden path. The behaviour is worse than would be observed on a real 12C or 17B. That would be my beef

I reiterate also that not everyone wants the 10Bii style. I prefer 12C style and most importantly, RPN. If Calc 12E did not exist then I would choose the best of the rest; probably a combination of allRPNcalc and the RLM 12C (both of which I have). Further, the 12C competitors out there are all, every one of them, way more expensive than the 10Bii and comparable with Calc-12E. Ricardo Lira Matte sells both the 12C and 10Bii but he pitches his RLM 12C at more than twice the price of his 10Bii.

Have you considered you may be comparing different markets, and ignoring functions of lesser interest to yourself? I tried to cover the "different things for different people" question in the other thread to which I refer, so I am not actually arguing against your preference for the 10Bii, if that is what it is, merely explaining that an alternative preference (and pricing) is rational and for some functions, critical.

### Re: Calc 12E: TVM zero-payment bug

Hi Xeno,

Appreciate your reply. I must confess I too like RPN better than algebraic input. I am still considering purchasing the 12E, but I must say I was a bit disillusioned after seeing the inaccuracies on "the calculator that was supposed to be more accurate than all the rest". RPN or no RPN, that little 10bii of Brock seems to be more accurate than the 12E. In my job and position accuracy is more important than input mode or anything else for that matter. I guess with all that has happened in our economy I have become disillusioned of people making claims that are not true. I am not saying the developers of the 12e intentionally misrepresented it, but none the less I would rather have accuracy with algebraic input (at $4.95), than wondering if I got the correct answer with RPN input (at $24.95). I think the Stonemeadow folks will work out the kinks in their calculator, but I guess I have become callous to claims that later fail to prove true. Nevertheless, I wish them well with their program and hope they work out the kinks for the benefit of their user base.

Best regards

Appreciate your reply. I must confess I too like RPN better than algebraic input. I am still considering purchasing the 12E, but I must say I was a bit disillusioned after seeing the inaccuracies on "the calculator that was supposed to be more accurate than all the rest". RPN or no RPN, that little 10bii of Brock seems to be more accurate than the 12E. In my job and position accuracy is more important than input mode or anything else for that matter. I guess with all that has happened in our economy I have become disillusioned of people making claims that are not true. I am not saying the developers of the 12e intentionally misrepresented it, but none the less I would rather have accuracy with algebraic input (at $4.95), than wondering if I got the correct answer with RPN input (at $24.95). I think the Stonemeadow folks will work out the kinks in their calculator, but I guess I have become callous to claims that later fail to prove true. Nevertheless, I wish them well with their program and hope they work out the kinks for the benefit of their user base.

Best regards

### Re: Calc 12E: TVM zero-payment bug

A few words...

I don't thing anyone "intentionally" puts out defective software (including Redmond), least of all me. The error was introduced by a feature addition and while I do what I can to avoid them (this error did not exist until v x.1.0), they do happen... this is software and we all know what that means. Updates allow me to correct my mistakes and since they're free you remain protected. I hope I don't imply that Calc-12E is perfect, it is by definition not perfect because it's a software implementation -- but I do believe that Roy's math is unequaled and as long as I get all of the i's dotted and t's crossed it has no peer among today's offerings.

As for pricing, and input styles and feature sets, IMHO that is what is so grandly excellent about both the App Store and the iPhone/iPod touch. As a consumer, I can choose my price point, my feature set, my look and feel, my level of mathematical retentiveness -- there are lots of offerings out there, they range from free (for simple auto loan estimators) to Calc-12E and offer feature sets that range from very simple to extensible, in algebraic and RPN and both! So I view the choices as a good thing, there need not be a single solution for all needs.

Stone Meadow (that is me) is driving to deliver a professional grade tool for daily use in business. One that will adapt to new features and retain the usability that is the hallmark of the iPhone. Our market is those that must have mathematical reliability, which means that a huge amount of work goes into the theoretical math that no one will ever see. THIS DOES NOT MEAN that an error will never be found -- but it does mean that any errors are most likely due to typos and are easily corrected.

I guess I'd ask for a couple things: First, a modicum of tolerance. I do support the product and will fix the problems and you get FREE upgrades when I do--but typos and misinterpretations do happen and all the testing in the world cannot uncover all of the unexpected issues (there is some interesting behavior in the 12C that much to his chagrin Roy has found while rewriting his algorithms). Second, I encourage you to shop around. I will not pretend to meet everyone's needs because I simply can't do that in a single product so if you need this and can do without that I'll be happy to try to help you find a product that meets your requirements. I know, it'd be wonderful if I could offer the one-ring-to-rule-them-all, but I don't have that kind of energy or expertise.

Kim

ps. I really like this kind of discussion, it provides fertile ground for my mind to work on new ways to address issues that current and potential customers have, so don't let me squash the thread!

I don't thing anyone "intentionally" puts out defective software (including Redmond), least of all me. The error was introduced by a feature addition and while I do what I can to avoid them (this error did not exist until v x.1.0), they do happen... this is software and we all know what that means. Updates allow me to correct my mistakes and since they're free you remain protected. I hope I don't imply that Calc-12E is perfect, it is by definition not perfect because it's a software implementation -- but I do believe that Roy's math is unequaled and as long as I get all of the i's dotted and t's crossed it has no peer among today's offerings.

As for pricing, and input styles and feature sets, IMHO that is what is so grandly excellent about both the App Store and the iPhone/iPod touch. As a consumer, I can choose my price point, my feature set, my look and feel, my level of mathematical retentiveness -- there are lots of offerings out there, they range from free (for simple auto loan estimators) to Calc-12E and offer feature sets that range from very simple to extensible, in algebraic and RPN and both! So I view the choices as a good thing, there need not be a single solution for all needs.

Stone Meadow (that is me) is driving to deliver a professional grade tool for daily use in business. One that will adapt to new features and retain the usability that is the hallmark of the iPhone. Our market is those that must have mathematical reliability, which means that a huge amount of work goes into the theoretical math that no one will ever see. THIS DOES NOT MEAN that an error will never be found -- but it does mean that any errors are most likely due to typos and are easily corrected.

I guess I'd ask for a couple things: First, a modicum of tolerance. I do support the product and will fix the problems and you get FREE upgrades when I do--but typos and misinterpretations do happen and all the testing in the world cannot uncover all of the unexpected issues (there is some interesting behavior in the 12C that much to his chagrin Roy has found while rewriting his algorithms). Second, I encourage you to shop around. I will not pretend to meet everyone's needs because I simply can't do that in a single product so if you need this and can do without that I'll be happy to try to help you find a product that meets your requirements. I know, it'd be wonderful if I could offer the one-ring-to-rule-them-all, but I don't have that kind of energy or expertise.

Kim

ps. I really like this kind of discussion, it provides fertile ground for my mind to work on new ways to address issues that current and potential customers have, so don't let me squash the thread!

### Who is online

Users browsing this forum: No registered users and 1 guest