The mortgage nomogram Leif was describing has two main parts.
If P is the loan amount (P stands for Principal),
m is the monthly payment,
i is the monthly interest rate,
and n is the term in months
then P/m = a = [1(1+i)^{n}]/i
Of course, the user wants the interest quoted as an annual rate and the term in years.
a is the value of an amount paid of 1 unit per time period at the given interest rate and term (often called an "annuitycertain", even when it's not paid annually).
I have made the right half of this equation into a nomogram (i.e. the tricky part), following largely the "one curvy scale" discussion I posted here recently. It worked pretty well for a first iteration, and the first time I've actually carried such a calculation right through.
Almost all of this work could be performed in code.
In the proofofconcept nomogram linked below (it's not production quality by any means), the annuity value, "a" is on a logscale. This makes the P/m=a part trivial (just a parallelscale nomogram), so the full nomogram would simply consist of the part below with m and P scales (also logarithmic) to the left of that; you pivot about the "a" scale value.
(NB  the "a" scale itself need not have numbers or even tick marks; it's really just a pivotscale between the P/m and the i/n halves. On the other hand, it may be of interest to have the values.)
Note that there are two values "drawn in" as a quick illustration.
15 years at 2.5% p.a. (compounded monthly)
and
40 years at 8% p.a.
The first should have a value of a=150.3, the second of a=148.3
[This means that for a 15 year loan at an annual interest rate of 2.5%, the monthly repayment will be 1/150th of the principal.]
As you can see, the first one comes out right on 150, and the second just below that. On a blown up version (400%), I was able to work out the value of the second one as 148 (to the nearest whole number).
The layout of the centre (years) scale  both the way it starts very close to the a scale, and its curvature at the high end means that there's some loss of accuracy from the highest interest rates, but with careful use on a big copy (the original file blows up well, though the jpg doesn't) the accuracy is pretty good. A wellchosen projective transformation (on the entire nomogram. including the P/m part) should help with that issue, but I haven't tried that.
Opinions? Questions?
(This image is hosted at my geocities website, so lots of views of it will max out my bandwidth there fairly quickly. I may have to put it elsewhere.)
[img]http://www.geocities.com/glenbarnett/loan.jpg[/img]
Half of a mortgage nomogram

 Posts: 27
 Joined: Mon Feb 04, 2008 9:43 pm
 Location: USA
 Contact:
Re: Half of a mortgage nomogram
Glenbarnett wrote:I have made the right half of this equation into a nomogram (i.e. the tricky part), following largely the "one curvy scale" discussion I posted here recently.
Hi Glen,
I understand why you might expect the a and i scales to be logarithmic, and I understand how you created the curved scale from overlays of lines of known solution, but how did you know that this form (two linear and one curved scale) would work out for this equation? Even when the logarithm is taken of both sides, it doesn't appear to align with the Genus I standard form unless I'm missing something.
I can store files on my website if that would work out betterjust let me know.
Ron
Re: Half of a mortgage nomogram
[quote="RonDoerfler"][quote="Glenbarnett"]I have made the right half of this equation into a nomogram (i.e. the tricky part), following largely the "one curvy scale" discussion I posted here recently. [/quote]
I understand why you might expect the a and i scales to be logarithmic,[/quote]
In fact I didn't expect a logarithmic form to work particularly well at all. I was working on powers (both fractional and inverse) and ratios of linear functions; all had some nice features, and it is conceivable all might have been made to work. I just happened to go back and give ln(a) another try, because of a feature I noticed about various power series (I forget actually, but I was playing around with power series and transformations, and noticed somethingorother and decided to try ln(a) again.
[quote] and I understand how you created the curved scale from overlays of lines of known solution, but how did you know that this form (two linear and one curved scale) would work out for this equation? Even when the logarithm is taken of both sides, it doesn't appear to align with the Genus I standard form unless I'm missing something.
[/quote]
Note that the scale for "i" is NOT a logscale. It's close to sqrt(i), but it is different.
You're correct, the equation is not of standard Genus I form. However, it is extremely well approximated by a relation of that form. Explicitly, you can write the relationship in this form:
ln(a) = f(n) + phi(n) I(i)
but I just can't say explicitly what f(), phi() or I() are, other than "they're some kind of fairly smooth curve". It's possible to try to recover those functions  or at least approximations of them  from the nomogram (I think I have a paper relating to it somewhere, but I have yet to read it).
Here's the approach I actually used:
i) I played around with graphs of "a" vs "i" for a vectors of fixed "n" values (yielding multiple curves). Once I realized that the curves of A(a) vs I(i) for fixed n were all nearly linear when A()=ln() and I()=sqrt(), I stopped. (They were far from the only candidates! Many other combinations of A and I functions were nearly as good.)
ii) I simply played (by hand) with the already almostlinearizing Itransformation, by pushing "up" the low values higher than they were under the square root, rapidly getting almost perfect linearity in the plot (for most values of n I couldn't distinguish the curves from lines of best fit).
At this point I no longer had an explicit functional form for I(), just Ifunction values that various ivalues mapped to. I didn't want to play with the ascale (since either a log transform or a power transform made the P/m side doable directly and I already had a logtransform). Fortunately, it was almost perfectly linear already, so there was no need.
The reason we look for linearity is because of the duality between the graph and the alignment nomogram; the important bit to know for now is that if these curves are straight, then an alignment nomogram exists.
So this linearity basically told me that I had a nomogrammable relationship, even though I didn't know what it was. However, I didn't [i]need[/i] to know what it was to draw it. I had my Iscale, marked with the values of "i" that I cared about, and I had my Ascale.
iii) I simply drew A and I scales on a graph (in Excel) as vertical axes at arbitrary locations, and then constructed the ncurve empirically (well, Excel did almost all the work  it would have been tedious to do by hand on paper). I used the drawing tool in Excel to help me draw a smooth curve through the selected scale tick marks (useful hint: don't use too many knots, and put knots between rather than at tick points  it seems to give better control, since you can slide the knots about more easily and end up with a smooth result). The broad approach here is described in my "one curvy scale" discussion  it's the part about the little triangles. (Lyle describes something very similar, but I hadn't read that when I wrote the curvyscale discussion, and didn't use his approach directly.)
All scales would be better with more tick marks, but that's just a matter of additional effort  it doesn't change the approach, which is all I was trying to illustrate.
[quote]I can store files on my website if that would work out betterjust let me know.[/quote]
Thanks. There are bots crawling all over this site, judging from the hit counts. If they follow the jpg link, it will get creamed. If they don't follow it, the few of times an actual human looks at it should be no major problem. I will check the traffic in a few days and assess the situation, so I may take you up on it then.
I understand why you might expect the a and i scales to be logarithmic,[/quote]
In fact I didn't expect a logarithmic form to work particularly well at all. I was working on powers (both fractional and inverse) and ratios of linear functions; all had some nice features, and it is conceivable all might have been made to work. I just happened to go back and give ln(a) another try, because of a feature I noticed about various power series (I forget actually, but I was playing around with power series and transformations, and noticed somethingorother and decided to try ln(a) again.
[quote] and I understand how you created the curved scale from overlays of lines of known solution, but how did you know that this form (two linear and one curved scale) would work out for this equation? Even when the logarithm is taken of both sides, it doesn't appear to align with the Genus I standard form unless I'm missing something.
[/quote]
Note that the scale for "i" is NOT a logscale. It's close to sqrt(i), but it is different.
You're correct, the equation is not of standard Genus I form. However, it is extremely well approximated by a relation of that form. Explicitly, you can write the relationship in this form:
ln(a) = f(n) + phi(n) I(i)
but I just can't say explicitly what f(), phi() or I() are, other than "they're some kind of fairly smooth curve". It's possible to try to recover those functions  or at least approximations of them  from the nomogram (I think I have a paper relating to it somewhere, but I have yet to read it).
Here's the approach I actually used:
i) I played around with graphs of "a" vs "i" for a vectors of fixed "n" values (yielding multiple curves). Once I realized that the curves of A(a) vs I(i) for fixed n were all nearly linear when A()=ln() and I()=sqrt(), I stopped. (They were far from the only candidates! Many other combinations of A and I functions were nearly as good.)
ii) I simply played (by hand) with the already almostlinearizing Itransformation, by pushing "up" the low values higher than they were under the square root, rapidly getting almost perfect linearity in the plot (for most values of n I couldn't distinguish the curves from lines of best fit).
At this point I no longer had an explicit functional form for I(), just Ifunction values that various ivalues mapped to. I didn't want to play with the ascale (since either a log transform or a power transform made the P/m side doable directly and I already had a logtransform). Fortunately, it was almost perfectly linear already, so there was no need.
The reason we look for linearity is because of the duality between the graph and the alignment nomogram; the important bit to know for now is that if these curves are straight, then an alignment nomogram exists.
So this linearity basically told me that I had a nomogrammable relationship, even though I didn't know what it was. However, I didn't [i]need[/i] to know what it was to draw it. I had my Iscale, marked with the values of "i" that I cared about, and I had my Ascale.
iii) I simply drew A and I scales on a graph (in Excel) as vertical axes at arbitrary locations, and then constructed the ncurve empirically (well, Excel did almost all the work  it would have been tedious to do by hand on paper). I used the drawing tool in Excel to help me draw a smooth curve through the selected scale tick marks (useful hint: don't use too many knots, and put knots between rather than at tick points  it seems to give better control, since you can slide the knots about more easily and end up with a smooth result). The broad approach here is described in my "one curvy scale" discussion  it's the part about the little triangles. (Lyle describes something very similar, but I hadn't read that when I wrote the curvyscale discussion, and didn't use his approach directly.)
All scales would be better with more tick marks, but that's just a matter of additional effort  it doesn't change the approach, which is all I was trying to illustrate.
[quote]I can store files on my website if that would work out betterjust let me know.[/quote]
Thanks. There are bots crawling all over this site, judging from the hit counts. If they follow the jpg link, it will get creamed. If they don't follow it, the few of times an actual human looks at it should be no major problem. I will check the traffic in a few days and assess the situation, so I may take you up on it then.
Great nomogram!
How about if you would just fit coeffs for polynomials
F1,F2,G2,F3 in function
F1(a)=F2(n)+G2(n)*F3(i)
such that error would be minimized for every combination
of a,n,i in specified range ?
This is of course the approach I already proposed.
I looked my code and found that I actually fitted for Ntype
nomogram:
F1(a)=F2(n)*F3(i)
so your curved scale nomogram with more degress of
freedom probably give better answers.
If you have transformed a to some func F1(a), then you have
to find F1(a)=F1(P/m) nomogram that is probably doable with
ladders, but maybe not trivial...
\leif
How about if you would just fit coeffs for polynomials
F1,F2,G2,F3 in function
F1(a)=F2(n)+G2(n)*F3(i)
such that error would be minimized for every combination
of a,n,i in specified range ?
This is of course the approach I already proposed.
I looked my code and found that I actually fitted for Ntype
nomogram:
F1(a)=F2(n)*F3(i)
so your curved scale nomogram with more degress of
freedom probably give better answers.
,P/m=a part trivial (just a parallelscale nomogram)
If you have transformed a to some func F1(a), then you have
to find F1(a)=F1(P/m) nomogram that is probably doable with
ladders, but maybe not trivial...
\leif
How about if you would just fit coeffs for polynomials
F1,F2,G2,F3 in function
F1(a)=F2(n)+G2(n)*F3(i)
such that error would be minimized for every combination
of a,n,i in specified range ?
This is of course the approach I already proposed.
Indeed you could attempt to fit smooth curves. In many cases there would be an advantage to doing so.
I wouldn't keep to polynomials alone, however. They're a good first thing to try, but they tend to have a problem fitting some kinds of function, where if you add enough terms to capture the shape, they wiggle about between the fitted points. One way to avoid that is to use, say cubic splines, or somesuch. (A common choice used with nomograms in the past by some engineers was ratios of linear or loworderpolynomial functions. I have found originshifted powers, (xk)^s for noninteger, and possibly negative "s" to be quite good at times. There are also families of transformations widely used in some areas that can be useful, which I should write about sometime)
One problem is that it's quite tricky to see the form of nomogram that you should use at the start. The handanamorphosis on the intersection charts yielded near straight lines, so from that point we were at a "straight parallel scales for "a" and "i", and then something of the form F1(a)=F2(n)+G2(n)*F3(i) is obvious in some sense.
Of course (as I suggested in my "one curvy scale" post, you can just start with "lets find the best approximation of the form h(w)=f(v)+phi(v)g(u)" and see if it works, so if that's what you're suggesting, then it certainly has the potential to work in many cases, it's a very rich set of relations.
The hard part is that even with polynomials, because you're including transformations of "a" in the search space, the search over possible transformations of the response makes the overall search space *huge*. Within any transformation of a, the problem is much easier (for a given maximum degree of polynomial, it's a matter of fitting coefficients by, say Linfinity norm, a standard problem), but finding the best transformation of "a" is hard, since it's a different kind of problem. (On the other hand, if you knew the functions for the other variables, the transformation for "a" would be estimable.)
In fact, given a good transformation of "a", the problem can be done for much more general classes of functions than polynomials (the book by Khavinson addresses this for equations of the form h(z) = f(x) + g(y)  the calculation of f and g is straightforward; I don't recommend Khavinson's book unless you're prepared for some pretty solid mathematics).
If you do the handanamorphosis, approximate values of the transformation of "a" that you're trying to approximate can be obtained from the transformation you used; similarly for "i". So at least doing that first stage by hand can make the problem much more manageable.
If you have transformed a to some func F1(a), then you have
to find F1(a)=F1(P/m) nomogram that is probably doable with
ladders, but maybe not trivial...
I was trying to avoid ladders, since they introduce a lot more inaccuracy.
But in any case, if you're trying to get a best fit (in some sense) for both halves, you have to consider both halves of the equation at the same time.
[I avoided that consideration by restricting myself to powers of a and the log function (which fits into the "powers of a" ladder, since
lim(p>0) [a^p1]/p = ln(a) ).
By using that restriction, I was keeping myself to things that meant P/m=a would be easily nomogrammed]
If you did go for a more general transformation of "a", you would have to look to get an approximation that worked on both sides at once. This is what I've been trying to do with the Rocket equation (I have a reasonable one, but I am hoping for something better).
(The equation in question is u/v + 1 = exp(x/y) ).
While it has some obvious similarities to the mortgage equation, it's subtly trickier.
I'm not sure that "best approximation" in the usual sense (whether Linfinity norm or something else) is the right metric. I think a more appropriate metric needs to take into account the errors from the using nomogram itself (which is not uniform across all input values). Ideally it's the error across the entire process that needs to be optimized.
Last edited by Glen on Thu Feb 25, 2010 5:11 am, edited 1 time in total.

 Posts: 27
 Joined: Mon Feb 04, 2008 9:43 pm
 Location: USA
 Contact:
Glen and Lief,
I just wanted to say thanks for taking the time to answer my question on the curvefitting process in such detail and for the further discussions on minimizing the error. One of the things that strikes me about nomography is the range of freedom available for different creative designs. Another striking feature is how much mathematics and effort lies behind these seemingly simple nomograms, which to me is an indication of how effective nomograms can be in representing quite complicated formulas.
Ron
I just wanted to say thanks for taking the time to answer my question on the curvefitting process in such detail and for the further discussions on minimizing the error. One of the things that strikes me about nomography is the range of freedom available for different creative designs. Another striking feature is how much mathematics and effort lies behind these seemingly simple nomograms, which to me is an indication of how effective nomograms can be in representing quite complicated formulas.
Ron
The sort of "automatic identification of smooth transformations" we've just been discussing is a problem I have been worrying at for a long time, but I always failed to figure out how to automatically identify the transformation of the response variable from a fairly general smooth class (e.g. from among splines or polynomials or whatever).
[It's easy enough to pick a transformation from a finite list, of course  just try them all and see which one fits best.]
This most interesting discussion we've been having has triggered an idea (actually, thinking more about Leif's question did it). It is just possible that I may have found a way to somewhat automatically identify an approximate transformation h() in relations of the form:
h(z) = f(x) + phi(x).g(y) .
(at least given some class of flexiblebutsmooth smooth functions to choose h() from among; normally you'd want h to be monotonic but I'm going to ignore it to begin with).
There are some details to work out, but if it works, it could be pretty neat. You'd supply a table of data ( x,y,z triples, or maybe a twoway table with x,y margins and zvalues for each combination). You'd get back out h,f,g, etc.
After coming up with the idea, I can see one further very good reason why ratios of linear or loworderpolynomials is attractive (aside from their ability to approximate rapidlychanging functions).
[Of course, it may not work out. Probably not time to try it for a while. I will discuss it here if it does work. I will probably write some code up in R, since a lot of the stuff I'll need will be builtin there.]
[It's easy enough to pick a transformation from a finite list, of course  just try them all and see which one fits best.]
This most interesting discussion we've been having has triggered an idea (actually, thinking more about Leif's question did it). It is just possible that I may have found a way to somewhat automatically identify an approximate transformation h() in relations of the form:
h(z) = f(x) + phi(x).g(y) .
(at least given some class of flexiblebutsmooth smooth functions to choose h() from among; normally you'd want h to be monotonic but I'm going to ignore it to begin with).
There are some details to work out, but if it works, it could be pretty neat. You'd supply a table of data ( x,y,z triples, or maybe a twoway table with x,y margins and zvalues for each combination). You'd get back out h,f,g, etc.
After coming up with the idea, I can see one further very good reason why ratios of linear or loworderpolynomials is attractive (aside from their ability to approximate rapidlychanging functions).
[Of course, it may not work out. Probably not time to try it for a while. I will discuss it here if it does work. I will probably write some code up in R, since a lot of the stuff I'll need will be builtin there.]
Re: Half of a mortgage nomogram
I have been working on the PyNomo project and as an demonstration managed to make amortization nomogram with exact equation. Half of nomogram is in spirit of nomogram from d'Ocagne 1899 book page 306. The nomogram may be downloaded from:
http://pynomo.org/examples/amortization_100308.pdf
I have worked in a framework to construct nomograms made out of multiple nomograms and there is still way to go. However, basic routines seem to work. Questions are mostly how to write good code and less about mathematics, yet.
\leif
http://pynomo.org/examples/amortization_100308.pdf
I have worked in a framework to construct nomograms made out of multiple nomograms and there is still way to go. However, basic routines seem to work. Questions are mostly how to write good code and less about mathematics, yet.
\leif

 Posts: 27
 Joined: Mon Feb 04, 2008 9:43 pm
 Location: USA
 Contact:
Re: Half of a mortgage nomogram
Wow, that's a greatlooking nomogram! It's so much easier, I think, to play with possible scenarios on a 4variable nomogram like this than to keep punching numbers into a calculator to see what comes out. If you were to increase the maximum value of the loan amount and decrease the minimum number of years to 1, it would be immediately useful.
I downloaded your PyNomo program and all the associated software (I already had MiKTeX) and I'm starting to explore it. Very impressive.
Ron
I downloaded your PyNomo program and all the associated software (I already had MiKTeX) and I'm starting to explore it. Very impressive.
Ron
Re: Half of a mortgage nomogram
RonDoerfler wrote:
I downloaded your PyNomo program and all the associated software (I already had MiKTeX) and I'm starting to explore it. Very impressive.
Ron
Note that I made loan nomogram with the PyNomo version under development. The Sourceforge latest version 0.1.0b1 is from October and it will take some time before I will make a new distribution. If you anyway want to play with the latest version, it can be downloaded from Sourceforge SVN. The file to look for building complex nomograms like loan calculator is found from file nomo_wrapper.py
A note to loan nomogram use: one has to find crossing of interest rate and years and draw vertical line down to bottom vertical line. This is the turning point for next line that goes through loan and monthly payment.
\leif
Who is online
Users browsing this forum: No registered users and 2 guests