Congratulations - you're 0.3 cents off, despite careful ad-hoc tuning you did to solve only the one set of numbers you set out to. Too bad your method still fai

Congratulations - you're 0.3 cents off, despite careful ad-hoc tuning you did to solve only the one set of numbers you set out to. Too bad your method still fails for a whole range of valid mortgages :) Like what happens when you use your algorithm for a 10M mortgage? Oops! Just add some more scaling, ad hoc fixes.... Then $100M? Oops! More scaling and fixes. And so on. Enough ad-hoc fixes and you'll re-invent float-point, but badly. This is why such ad hoc goofiness is a bad idea. Despite you trying real hard to make a good algorithm, you still failed. Try using modern high decimal fractional mortgage rates. Oops. Try using a longer term, like long term rentals of commercial land for 100+ years. Oops again! Yet my one line floating point code handles them all, no fiddling, no errors, no chasing down bugs every time someone puts other numbers into the code. Are you going to hand fiddle everytime? Try other rates, some times rates are many more digits than you assume - are you now going to hand analyze each single problem and hand code a single problem solver? Floating point does them all. Of course, you will eventually stumble onto more and more precision, then you will fail to handle large numbers. Eventually you might try using two 64 bit integers, more or less trying to accomodate what a double simply does out of the box. And then you will have reinvented floating point numbers, just much slower and more error prone. You're replacing floating point which just works, by having to be super careful of order of operations, thereby making it more likely a programmer without knowing the nuances of numerics will fail. Prime example: you decided to replace a rate, converted to percent with a division, then to a per-time step with another a division, by a multiplication. Why? because if you didn't you puke as I demonstrated. You also needed to do some prescaling, leading to bugs. Not all prices are in pennies. Then you needed to "assume" principal was in pennies. Why? to make your ad-hoc method work. Mine worked in dollars, yen, lira, pesos... all sorts of scales, and yours would need tweaking and hackery to handle all the scaling you will need for wide ranging currencies (or dollar amounts) - each leading to bugs. >Thanks for playing. You're welcome. If you really want to play, let's each put forth a single code snippet, and see if the other one can propose a simple mortgage representative of one in the real world that breaks the other's code. Care to play? So write your best method to calculate mortgages, across any type of simple mortgage I will pick (principal P (in an arbitrary currency), annual rate r (expressed as percent), compounding rate t per annum, term in years n), and I will submit my floating point code against yours, and I will demonstrate yet again why yours fails. My code: total = principal * (1+((rate/100)/t)) ^ (n*t) No many places to make a mistake there. And your code? So far your method seems more ad-hoc and error prone than pretty much anything any programmer simply copying a formula out of a book would end up with. This is exactly why your advice is bad. It will lead to people making mistakes :) >Thanks for playing. You're welcome. It has been enlightening. I look forward to your next algorithm.