Amortization Calculator – Page 2 – Bret's Blog (2025)

In responding to a question in blog comments about rate-finding, I noticed that the calculator didn’t behave well if the Payment Amount could not pay off the loan after the Number of Regular Payments had elapsed, no matter how low the interest rate. To fix this, I added a test for the condition and have the calculator write an error message if necessary.

It’s a little surprising to still find bugs of this magnitude after all these years. 🙂 But hey, they’re still getting fixed, one by one.

Well, it has happened. What I have feared the most. Calamity. Pain. Suffering. Ego-shattering. In moving the calculator to its new home, it lost its long-held rank as the number one result for the search “amortization” on Google. It is now number two. I am properly admonished and duly humbled.

As for progress, the calculator page now validates as XHTML 1.0 Transitional. It’s a small thing, but I believe in standards.

Having been truly inspired by the work at the CSS Zen Garden, I will try my hand at making visually aesthetic improvements to the calculator web page. There’s no reason why function can’t also be beautiful. However, my skills as an artist are—shall I be generous?—limited. Someday I’d like to hire the services of a graphic designer to make it REALLY cool and pretty.

I’ve added a new entry to the FAQ regarding negative amortizations. In the process, I also noticed that some of the summary information produced by the calculator and final schedule row are not completely consistent in the NegAm scenario. I will need to fix these. It is apparent that I missed some sort of symmetry in my calculations here (I probably took a shortcut to minimize computer time, which is just so much gagging at gnats these days).

This is interesting to me because I’ve recently been reading some of the Richard Feynman Lectures on Physics, and he talks a bit about mathematical symmetries. We have such an expectation of symmetry that lack of it in certain contexts may indicate a flaw in our understanding, or sometimes it may lead to the discovery of even more interesting properties. (Amortization is not so glamorous as a fundamental law of the universe, mind you; but I now recognize that had I paid closer attention to a mathematical symmetry in this case, I might have noticed my error sooner.)

I improved a test for an error condition yesterday. If one tries to find out how long it will take to pay off a loan (i.e., the Number of Payments field is blank), but the Regular Payment amount specified is below the minimum amortizable payment, the loan can never be paid off, since the payment isn’t even covering the interest that’s due. In such a case, the calculator raises an error condition.

This test existed before, but it wasn’t always reliable right at the cusp of amortizability, so I made a tweak which should have handled it. It did the job as I intended, but there was a consequence: it also disabled negative amortization scenarios if one is seeking a payoff time when a Balloon Payment has been also specified. So I have fixed yesterday’s fix, and finding the loan payoff time for a negative amortization scenario should work again.

I also added a link to this blog from the calculator page itself, for the curious.

As of July 2nd, 2008, the Amortization Calculator was officially moved from its old location in the Meteorology Department of Florida State University to this website. The primary impetus for the move is that the aging machine on which the calculator had been running since the mid-90s will soon need to be shut down for good. In fact, running the calculator was about all the old machine had been doing for the last 4 or 5 years.

Since I had to recompile the calculator program as part of the move anyway, I took the opportunity to make a few little tweaks to the design, and to make a few minor bug fixes and enhancements. The biggest visible change is the addition of a Google ad bar, which I’m sure will annoy some folks (and I can’t say I love the look myself). However, where web and network services were provided to the world “for free” by the university, *I* am now paying so that folks can continue to have access to the calculator. I think it’s only fair.

So in case anyone is interested (and if you’re not, that’s OK: this is just a personal record of my work), here are some of the changes that I’ve made to the calculator while moving it to its new home.

General Changes

• If the calculator does not receive HTTP POST data, rather than complaining, it now draws the default web form. Previously, POST data had to have been received for the calculator to plot anything.
• I made some variables pertaining to errors global (versus local) so that error messages could be properly propagated and displayed to the user.
• The calculator now makes extensive use of CSS, which makes tweaking the layout so much easier. It also means that error messages are able to be displayed properly, in a nicer context.
• For consistency, the support pages (the FAQ and Info pages) use the same stylesheet, although their layout does need to be tweaked a bit more before I’ll be really happy with them.
• The source code has been refactored, especially as it pertains to web page output. It should be easier to make changes/additions to the calculator page now.

Enhancements

• I tried to make the error messages more explanatory, less computer jargony, and to perhaps assist the user in correcting an issue where possible.
• I added some additional calculations to the “Summary” section: the number of years is calculated from the total number of payments, and now the minimum payment required to amortize the loan is calculated. (Payments less than this amount do not allow for any principal reduction, and in fact, may cause unpaid interest to accrue into additional debt.)
• I trapped a few more error conditions, which might cause the calculator to provide misleading data in fringe cases. I thought of a few more conditions I can try to address some other time.
• The state of the “Show Amortization Schedule” flag is now maintained between invocations. Previously, the flag was purposely reset between invocations because of the extra processing load incurred. We have more powerful machines now, so who cares? 🙂

I probably left some things out, but I think I hit the highlights.