Correct 12C operation

Things that aren't right, that are in the queue to be fixed... along with workarounds.
theDev
Posts: 240
Joined: Mon Aug 04, 2008 8:58 pm

Re: Correct 12C operation

Post by theDev » Sat Nov 29, 2008 4:35 pm

ts and Xeno!

I love the lively discussion and am glad that it has not gone to a full boil.

I for one, need y'all to be identifying the bugs--I hate to say it but both Roy and I are actually human and do make mistakes. I work to get them fixed as quickly as they are pointed out, I do hope that my support level is high enough to maintain confidence in my product. Rehashing history while entertaining to some, can come across as rather negative in tone... by gum I fixed that!!!

As to my claims. Lofty ones they are In the face of bugs. I make the claims because I understand a little of the math theory that Roy has put into the new algorithms, I would not have turned to him for help if I felt that the underlying math was as simple as I thought it was when I started out. But it's not, and while I eventually would have gotten to where I am today accuracy-wise, it might have taken thirty years and then I might as well call it Vista-12E. With Roy, underneath my inevitable coding error lies exceptionally robust math... if Roy's work were not as solid as it is, finding and fixing the bugs that stray into the code would be a whole heckofalot harder than it has been--bug hunts have taken 10s of minutes, not hours or days. Great for me, but it speaks most highly of Roy's math that his solution is straightforward enough to limit the bugs to implementation problems, and they are not flaws in the theory (which would be much much more difficult to deal with). That is the basis of my claim and the reason the calculator is (I think) the most expensive one on the App Store. I believe that getting Roy's expertise as the basis of a 21st century implementation is worth the premium I charge, and as a bonus you are buying into a platform that can and will go forward and build upon the work that HP started 30+ years ago. The products based on ROM emulators are unfortunately fairly static because their foundation (HP's ROM code) is also static, and that makes it exceptionally difficult to take them anywhere but where they were 30 years ago. By having Roy do a "do-over", I have a live platform to work with, a luxury lost to those relying on an ancient ROM image. I suppose I could rag on the HP emulators for what the 12C does if a bond's settlement date is August 30, or that they don't do amortization properly, or that they can't compute the number of periods any closer than the nearest integer but to be honest I don't view HP or the emulators as "competition"... I see the past as a brilliant legacy, one that thanks to Roy I get to pick up and tweak for a new hardware platform.

At any rate, as I've said before, choice is what makes the App Store so great. You get to decide what is right for your needs, be it my Honda-priced (but still a bargain) calculator or a Yugo. If the Yugo does what you need it to do, I would hope that your don't expend too much of your life force mumbling under your breath about me having the gall to ask the equivalent of a second-run matinee for two and dinner at McDonalds. Forgive me, I'm preaching to the choir. Each of us did turn down free phones or a transistor radio and elected instead to give Apple at least USD200 because it was "better" didn't we?

Yes, there have been problems and if you're surprised by that then you've been buying software from a very special source indeed. I do support this product though, and am quite confident that if you allow me the grace typically alloted a software geek that you will be quite happy with your purchase.

Kim

Bigben
Posts: 2
Joined: Sat Dec 20, 2008 1:48 pm

Incorrect with YTM

Post by Bigben » Sat Dec 20, 2008 2:09 pm

This program shows errors in calculating bond YTM.

Example
S=11.152008
P=28
CPN=7.75
M=5.152013
Ans YTM =49.78
The answer should be the same as
N=9
PV=-28
PMT=3.875
FV=100
The ans for I=24.1691. Multiply by 2 =48.34 which is correct.
Real 12C’s give the correct answer

Xeno
Posts: 55
Joined: Sat Oct 25, 2008 4:15 pm

Re: Correct 12C operation

Post by Xeno » Sat Dec 20, 2008 9:06 pm

I had a look at this. Basically, there are errors from the day after the semi-annual coupon date through to the next anniversary date. This recurs yearly. It is correct from the anniversary date through to the next semi-annual coupon.

The errors are very small from the coupon date until the first of the next month when the error difference jumps, and gradually declines until it is zero at the next anniversary date, implying some proportional error within the month after the semi-annual coupon then a fixed error is added (a coupon?) whose effect declines over the remaining six months.

I have sent some examples by PM.

theDev
Posts: 240
Joined: Mon Aug 04, 2008 8:58 pm

Re: Correct 12C operation

Post by theDev » Sun Dec 21, 2008 10:41 am

Thank you BigBen! Believe it our not I need these kinds of things pointed out because try as I might, I can only test "so much". I'll use Xeno's clues (thank you Xeno) to start the bug hunt.

Bigben
Posts: 2
Joined: Sat Dec 20, 2008 1:48 pm

Re: Correct 12C operation

Post by Bigben » Sun Dec 21, 2008 3:02 pm

If you would, like send me your equations that you use and I think it can be corrected very easy.

theDev
Posts: 240
Joined: Mon Aug 04, 2008 8:58 pm

Re: Correct 12C operation

Post by theDev » Sun Dec 21, 2008 7:53 pm

I'm going to give Roy first crack... (it's only fair after all!). As is traditional with root solvers, Roy uses a Newton solver (with embelishments) to arrive at a yield--Based on your example coupled with Xeno's example set we're focusing on ensuring that the dates passed to the solver are spot on because we did change things from the HP way to deal with maturity dates near the end of August (HP gives Error 8 if the six month interval falls into impossible dates in February so in essence you can't have a maturity date of Aug 30 or 31 and the 29th is only allowed on leap years). That change "shouldn't" affect maturity dates in the middle of the month... the operative word is "shouldn't".

Kim

theDev
Posts: 240
Joined: Mon Aug 04, 2008 8:58 pm

Re: Correct 12C operation

Post by theDev » Mon Dec 22, 2008 3:18 pm

good news...

The problem is a pair of typos in the code (a minus sign was supposed to be a plus sign and a "1" was supposed to be a "0"), easily corrected. In the process, I also stumbled across another problem with bonds that are less than 6 months settlement to maturity, where I failed to multiply an internal result prior to presenting it on the display. Consequently, if you solve a problem such as:

settlement date: 15 JUN 2008
maturity date: 16 JUN 2008 (or any date up to 14 DEC 2008)

you'll need to multiply the YTM result by 200 to get the correct answer.

I'll get the fixes rolled out shortly, I will probably hold off and release them as part of a scheduled update planned for January but if that update doesn't meet its present schedule the fixes will roll out anyway.

I hope this timetable will be acceptable...

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest