On 8/12/2018 12:58 PM, azalea4va wrote:
Sorry, I missed this reply. So a little late, but ...
I should perhaps have indicated that writing this sort of thing used to
be "my line of country". I have written these things.
Mike or Penny Novack-3 wrote
a) method? << by "present value" of series of "rents" or by "trial and
error" >>
I am not sure what ""present value" of series of "rents"" means, but the
answer is by math. This is just a mathematical calculation. As was
indicated in the code provided. I did not specify, but the math was based
on 30/360 calculations, the one most often used in determining mortgage
payments.
OK --- The periodic payments are called "rents" and dependent on the
"discount rate" (the mortgage interest rate in this case) that series of
future payments has a PRESENT value. So ONE way of doing the math is to
take the payment amount to be 1.0000... (number of decimal places not
going to be agreed) and discounting each by the interest for the
interval. That gives a number you can divide into the starting principle
amount.
Another way for a program to address the problem is "trail and
error"where starting with an initial guess as to what the payment would
be this is adjusted until the "best fit" results << see my question
about "final payment" >>
Mike or Penny Novack-3 wrote
b) where will rounding take place?
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. Since you and the bank will not be in
agreement won;t get the same answer. Again I will refer to the alternate
"trial and error" method of calculating the payment which MIGHT give
better results.
Mike or Penny Novack-3 wrote
c) how will the final payment be figured?
To be honest, I forget (because I do not care). Did I add the code to to
make the final payment the amount due at that time?
Again, there are choices here. Was the calculation made so that there
was NO additional (small) payment at the end? Was the calculation such
that the final payment would be as close as possible but not more than
the rest of the payments? What do you do IF the choice is between a
final payment much smaller than the others or going over a small amount
if the payment amount is 1 cent higher?
Do these issues explain why (in practice) my "amortab" programs (create
an amortization table for a loan amount, interest rate, and number of
payments) were usually written to use the "trial and error" method? << I
might get a first approximation by calculating the "present value" and
THEN seeing if small adjustments up or down gave a better fit to all the
desired conditions. >> For understanding what I mean by "trial and
error" methods look up something like "Newton's Method" -- I was NOT
referring to "non-math" but an algorithm, a PROCESS, guaranteed to
converge on a best approximation of a value.
Michael D Novack
_______________________________________________
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.
