iPhone SDK现值功能

Question

Present value is the value on a given date of a future payment or series of future payments, discounted to reflect the time value of money and other factors such as investment risk. Present value calculations are widely used in business and economics to provide a means to compare cash flows at different times on a meaningful "like to like" basis.

http://en.wikipedia.org/wiki/Present_value

What would be the best way to tackle this in an Objective-C function?

double retire62 = [benefit62.text doubleValue] * [yearlyReturn.text doubleValue] *12* [lblAgeExpectancy.text doubleValue];
double retire66 = [benefit66.text doubleValue] * [yearlyReturn.text doubleValue] *12* [lblAgeExpectancy.text doubleValue];
double retire70 = [benefit70.text doubleValue] * [yearlyReturn.text doubleValue] *12* [lblAgeExpectancy.text doubleValue];

Im just not familiar with Present Value/

Answer 1

Putting aside your code snippet for a little while, the present value calculation itself is reasonably straightforward, a least in its simpler forms. (It can become a fair bit more complicated if you start to consider more realistic interest with different rates at different terms and such, but if you want to get into that you'll need to do some proper reading up.)

The present value of any single future cash flow is the amount of money you would have to invest now (at the so-called risk-free rate ) in order to have the future amount when the time comes. That is, it is the future amount discounted at the specified interest rate.

As a trivial example, suppose you are going to give me $105 in a year's time, and the annual interest rate is 5%. If I have $100 now and invest it at that rate, in a year's time I will have $105, the same amount you are due to give me. So the present value of that future $105 is not $105, but only $100. (This is just a slightly more formal equivalent of observing that a bird in the hand is worth two in the bush.)

Let's take a marginally more realistic example just to see how the calculation works. Suppose I'm due to receive $1000 in 5 years -- how much is that worth to me now?

Assume again that the relevant interest rate is 5% per year, and further assume that it is compounded annually -- which is to say, after a year the first 5% is added to the original amount and this combined amount then accrues interest over the second year, and so on. After each year I have the amount I started with the beginning plus the 5% interest on the amount -- that is 1.05 times what I started with at the beginning of the year. So after five years I would have 1.05 * 1.05 * 1.05 * 1.05 * 1.05 times as much as I had right at the beginning. To have $1000 in five years I would have to invest $ 1000 / 1.05 * 1.05 * 1.05 * 1.05 * 1.05 , or about $784 -- and that's the present value of that $1000.

More generally, you would need to divide the future amount by pow(1 + r, n) for interest rate r and number of years n (or equivalently multiply by pow(1 + r, -n) ), and there are simple generalizations for where the interest rate and payments are over different periods (eg, annual rate compounded monthly). See, eg, Wikipedia's compound interest entry for more detail.

OK, back to the question. Coding this calculation in Objective-C is no different from coding it in C. Again using the simple version described above:

double presentValue ( double futureValue, double annualRate, unsigned int years )
{
    return futureValue * pow ( 1 + annualRate, -years );
}

You could do this as an Obj-C method rather than a C function, but the essence would be pretty similar. Adding more sophistication in terms of compounding periods and such is left as an exercise.

Note, however, that this doesn't bear very much resemblance to your own code, which looks to be just grabbing values blindly from text fields and multiplying them together. If you find yourself doing maths directly on the contents of views, you probably ought to be hearing alarm bells somewhere.

Not wishing to sound too high-horsey, but it seems to me that you need much more clearly to distinguish the underlying data (we could call it the model if we were being fancy) from the inputs (in other words, what is the user actually providing and what is the program expected to know how to do without them having to think about it). And furthermore, both these things should be considered separately from the UI elements used to represent them.

In other words, you probably need to revisit the whole Model-View-Controller pattern that every iPhone developer is supposed to have tattooed on their heart ;)