>> I addressed this in the file I provided. There is one and only one >> correct >> answer mathematically. > > Not true.Depends, for example, on how many decimal places in the > calculations and whether only final rounding or rounding at multiple > places during the calculations.
This was a terminology problem. When I said mathematically, I meant using exact math. That is not looking how a lender would implement but as a pure math problem. In a pure math, there is no rounding, it is just a calculation. > Again, there are choices here. yes there are choices, probably an infinite number of them. Anybody can invent any weird scheme for how this stuff gets process. I do not know about the rest of the wrold but here in the US almost all "legit" lending institutions (banks, etc) sue one of three schemes: 30/360, actual/365, and actual/360. Of those, for things like mortgages, 30/360 is the norm. So as I said in my reply (but did leave out in my original post), my answer was a solution for a 30/360 loan, again because that is what my bank uses as do most bank in the US. Si I agree there are lots of ways to compute loans, but this was a 30/360 solution and with that said only minor variations in how rounding occurs are possible. > Depends, for example, on how many decimal places in the > calculations and whether only final rounding or rounding at multiple > places during the calculations. All financial institutions use computers and are going to perform the calculations using at least 64-bit accuracy. If you use more (or even only 32-bit), that will make hardly any difference. The rounding issue only ocurs when that computer value must be translated into currency (in my case, US dollar/cents). I can only think of two options of when this would occur, as I detailed previously. Yes other rounding scenarios can be invented, but they have no place in real life "legit" lending scenarios. Note the use here is to create a scheduled entry in gnucash. That is, have gnucash autmatically add an entry into one's gnucash account each month for each payment. Although one could use it to generate an amoritization table, that was not its primary purpose. > Do these issues explain why (in practice) my "amortab" program .. were > usually written to use the "trial and error" method? Yes but again, that is not the type of loan I was creating a solution for. A perhaps interesting aside. I am a computer science professor whose career was at liberal arts universities. One example I would give of the value of a liberal arts education was it teaches people different approaches to looking at problems and that provides a better "tool kit" for problem solving. A mathematician can take your problem and generate a solution figuringing out the equation. A computer scientist can write a script and have it plug in millions of values until one of them generates the correct result. To radically different thought processes on how to arrive at an answer. One thing trail/error requires is knowing what the end result must be. So yes it works if you are trying to get a payment that leaves a final payment of 0 (smething I have never seen in a "primary" loan agreement). I do not see how trail/error could be used for a "normal" 30/360 loan because after a trial I do not see a way to evaluate if the result was an error or not (except to compare to the actual math answer, which eliminates the need for trail/error). If your response is one compare the result to the amortization schedule provied by tha bank, then there is no need for any of this, if I have that schedule I can just use that to determine what happens each month. -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
