[GNC] Loan/Mortgage payments with "adjusted" principle (eg after an extra principle payment), SOLVED

azalea4va common17.nabble at azalea.name
Mon Aug 13 11:29:26 EDT 2018


>> 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


More information about the gnucash-user mailing list