
Books about coding financial systems
I'm working on a new system that is heavily financially based. Lots of formulae about Compound Interest and Net Present Value.
Can anybody recommend a good book that could help a programmer understand it all.
At the moment the code seems to be unecessarily complicated because each formulae is treated as a separate entity, where I can see patterns between the formulae which hint at a common root.
Unfortunately, my knowledge of the math involved isn't good enough to work out what that root is, but I'm sure that a better knowledge of the formulae could lead to much better code. I suppose a good domain knowledge always does.
Ged Byrne
Wednesday, June 5, 2002
I just read a book on basic finace which gave the mathematical formulae and info on those terms.
Matthew Lock
Wednesday, June 5, 2002
Matthew,
I have the formulae and an understanding of what they do, but It seems to me that these formulae have all been highly streamlined to help make them easy to be calculated by hand.
I can see patterns, and my math is good enough to recognise when calculus has been used, but not good enough to reverse engineer.
For a human accountant it is easier to have lots of concise formulae and apply the most convenient, but this is not necessary for programming, and just adds unneccessary complication.
As an example, consider the calculations for NPV. There are several formulae given. There is the general term, a simplified equation for when all payments are equal, a much simplified version for when there is a single payment after 1 year and another for a mid year payment.
This helps a human accountant, who selects the simplist equation for their needs and saves a lot of time. However, for the computer it is just and fast and simple to use the general term in all cases.
The calculations in this code are more complex than this, and the application uses highly convulted code that attempts to emulate the decision process of a human accountant as he selects the easiest formulae for the job.
Unfortunately, nobody seems to know the general term. They just know the specific formulae.
Ged Byrne
Wednesday, June 5, 2002
Check these algorithms:
http://finance.bi.no/~bernt/gcc_prog/algoritms/algoritms/algoritms.html
They are in C++, but you could adapt them to whatever language you are using.
There is also a PDF here of Financial Numerical Recipes, though I have never read it.
http://finance.bi.no/~bernt/gcc_prog/algoritms/algoritms.pdf
Matthew Lock
Wednesday, June 5, 2002
Matthew,
Thanks for the info. It looks good.
Ged Byrne
Wednesday, June 5, 2002
Also do some research on "Reverse Polish Notation" which is the mathematical innovation that allowed calculators to calculate comound interest. If you can understand the HP12C calculator, you should be able to write a program that will calculate compound interest.
MarkTAW
Wednesday, June 5, 2002
>Also do some research on "Reverse Polish Notation" which is the mathematical innovation that allowed calculators to calculate comound interest. If you can understand the HP12C calculator, you should be able to write a program that will calculate compound.
You are absolutely kidding here right? RPN has absolutely ZERO effect on the calculators ability to figure out compound interest. I grew up using both HP calculators (RPN), and non RPN calculators. I am trying to figure out how RPN helps a calculator figure out interest?
I would perhaps say the use of log rmythic functions in a calculator that allow a number easily to be taken to a power of N would be the innovation here. (you do realize that the log functions are used to accomplish this...right?...recall your high school math  when you add two numbers as logs, you are actually multiplying....when you multiply two logs...you take to the nth power).
RPN simply is a means of notation. In fact any standard math expression can certainly be compiled into a RPN or stack notation, but that has got nothing to do the calculators ability, or some type of innovation that allows compound interest????
Perhaps you might want to explain a bit more as to what you mean here. Virtually all of the rpn functions in a calculator can in general be reproduced on a standard desktop calculator that has a few memory buttons anyway!
To the original poster: The compound interest formula is:
FV = P (1 + r) ^n
FV – Future Value, P = pricinpal, n = years
Hence, any calculator with a y to the X power button will accomplish this calculation. If your calculator is a RPN calculator, without the y to the X power function (*and* no log function) RPN is not going to save the day, nor is it worth a hill of beans.
To the original poster. It certainly does help to have taken some “Math of Finance”. The main thing you will learn in those courses is the concept of moving money back, and forward through time. I am tempted to go and dig up my old Math of Finance text from my University days. There is a base set of formulas and calculations that you use. With those functions and formulas, you can learn to lay out and solve just about every money problem you can think of.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Albert D. Kallal
Wednesday, June 5, 2002
Ged
The basic maths is very simple  no calculus is required for calculating NPV (although it can be for some methods of calculating IRR)  and the principles should be explained in the early pages of any book on corporate finance  eg "Principles of Corporate Finance" by Brealey & Myers. If you have the manual for an HP financial calculator available  eg the HP12C  then that should also give a good short summary of the calculations.
Basically, the present value of an amount C received n time periods (eg months, years) in the future is C/(1+i)^n, where i is the interest rate per period. For some reason 1/1+i is usually represented by v in the antipodes, so the formula is Cv^n. To get the present value of a series of cashflows, just add up all the Cv^n terms. The special cases arise, for example, when all the cashflows are equal and equally spaced, so you get a series such as:
Cv + Cv^2 +Cv^3 + ... Cv^n
which is a geometric progression, and can be explicitly summed to give:
C(1v^n)/i (assuming i is nonzero)
Somewhere at home I may have a Word document I wrote a while back about pricing Australasian financial instruments  mainly bonds  but the basic principles should apply to what you are doing. I could send you a copy if you like  email me if so, and I'll try to dig it out.
Andrew Simmons
Wednesday, June 5, 2002
Ged,
I'm in the same boat, I work for a fund management company at the moment and have to dredge up similar stuff. I recommend the EXCEL online help. I often use excel to support/test my visual basic/c routines. I think the help provided with the financial functions is OK.
Tony
Wednesday, June 5, 2002
There is a base set of formulas and calculations that you use. With those functions and formulas, you can learn to lay out and solve just about every money problem you can think of.
 Albert
Albert,
This is exactly what I'm looking for.
From the formulae I have, I have already been able to discern that they incorporate calculations for NPV and compound interest, but they don't account for everything the formulae does.
Is there any way of reversing calculus  ie to find what the original series was?
Ged Byrne
Thursday, June 6, 2002
Please Please Please do your employer a favor and don't reinvent the wheel. Find the algorithms in a library and buy it if you have to. It will be a factor of 10 times cheaper than for you to train yourself, code it, debug it, and maintain it.
Bella
Thursday, June 6, 2002
Here ya go in Python
http://metro.yak.net/pyfi2.py
Dan Sickles
Thursday, June 6, 2002
Ged: Is there any way of reversing calculus  ie to find what the original series was?
I'm not sure what you mean by this  in general, a given PV can be generated by an infinite number of different cashflow series. In special cases, the answer may be yes  eg an annuity relates PV, period interest rate, number of payments, and payment amount. If you know any three of these, you can solve for the fourth, although you may need an iterative solution for interest rate.
Bella's advice to buy rather than make your own is in general good. However, my experience of commercial finance packages is that they:
a) Tend to be of poor quality
b) Are inordinately expensive
c) Beyond the very basics, don't do what you want anyway
Andrew Simmons
Thursday, June 6, 2002
Thanks for the advice. I am making progress here.
Ged Byrne
Friday, June 7, 2002
He should go through a software selection methodology, and judge for himself. A blanket statement like that is fairly useless. There are plenty of libraries that have been refined over many many years, and are in use by many major banks.
Bella
Friday, June 7, 2002
> A blanket statement like that is fairly useless.
Maybe, but I can't see it's any less helpful than a blanket statement to the effect that buying a package will always be a factor of 10 cheaper than writing your own. Perhaps I might more accurately have said that, in my experience, you can get at most 2 of the following:
a) Low cost
b) Reliability
c) All the functions you need
With regard to point a, vendors of financial software seem to operate on the same principle that Philip Greenspun claims is used by vendors of database software  hang the user up by his heels, see how much money falls out, take it all and then ask for another $50,000 for "support". Banks have very deep pockets, and can afford to settle for b & c.
With regard to b, I have learnt to be mistrustful. For example, I once spent a day tracking down a "bug" in my date calculation function in a bond pricing module. The bug turned out to be due to the fact that Excel, which I was using to validate my calculation, is under the mistaken impression that 1900 was a leap year. Or again, I once wasted a fair amount of time trying to validate a cumulative normal distribution function I had written for an option pricing module against the NORMSDIST function in Excel because, as far as I can tell, the function is only accurate to 7 or 8 decimal places. Even the HP12C, which is, or used to be, the industry standard calculator, gets some bond price calculations slightly wrong, although the problem seems to have been fixed in later models.
With regard to c, the problem is that there is apparently no limit to the variety of financial instruments people will dream up, especially in the derivatives world, and supporting them all in a commercial package is difficult.
Andrew Simmons
Sunday, June 9, 2002
The system is not for a bank. It is for calculating a range of credit options on a point of sales system.
The customer appears to consider their formulae as a 'Trade Secret.' I think they're pround of the complexity and the fact that they are so difficult to understand, so they wouldn't go for the idea of using an offtheshelf package.
However, as I am uncovering, underneath they are just a set of basic calculations that have been refined for manual calculation over the years.
Thanks for the advice.
Ged Byrne
Monday, June 10, 2002
Recent Topics
Fog Creek Home
