add futureValue and computeInterestIncrement to fin.scm

as announced by jsled in http://lists.gnucash.org/pipermail/gnucash-user/2005-February/012964.html
additional improving of comments

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@22395 57a11ea4-9604-0410-9ed3-97b8803252fd
This commit is contained in:
Frank H. Ellenberger 2012-09-16 13:17:34 +00:00
parent 91f76f4eea
commit 15476e3de0

View File

@ -15,7 +15,12 @@
;; 51 Franklin Street, Fifth Floor Fax: +1-617-542-2652
;; Boston, MA 02110-1301, USA gnu@gnu.org
;; Financial functions originally used by the mortgage/loan druid,
;; but useful in scheduled transactions
;;
;; Copyright 2002 Joshua Sled <jsled@asynchronous.org>
;; Update 2012 Frank H. Elenberger <frank.h.ellenberger@gmail.com>
;;
;; Simple function for testing:
@ -25,6 +30,7 @@
;; positive values to be returned (as gnucash will handle the credit/debit
;; appropriately)
;; interest payment amount:
(define (gnc:ipmt rate per nper pv fv type)
(* -1 (* rate
(- 0 (calc-principal pv
@ -33,6 +39,7 @@
))
)
;; principal payment amount:
(define (gnc:ppmt rate per nper pv fv type)
(let* ((pmt (calc-pmt rate nper pv fv type))
(ipmt (* rate
@ -42,9 +49,30 @@
(* -1 ipmt))))
)
;; payment amount:
(define (gnc:pmt rate nper pv fv type)
(* -1 (calc-pmt rate nper pv fv type)))
;; 2 functions from http://lists.gnucash.org/pipermail/gnucash-user/2005-February/012964.html
;; future value of deposits with compound interests:
(define (gnc:futureValue a r n t)
;; Parameters:
;; a: amount
;; r: interest rate
;; n: frequency per year
;; t: time
;;
;; formula from http://www.riskglossary.com/articles/compounding.htm
(* a (expt (+ 1 (/ r n)) (* n t))))
(define (gnc:computeInterestIncrement amount interest periods i)
(let ((thisVal (gnc:futureValue amount interest periods i))
(prevVal (gnc:futureValue amount interest periods (- i 1))))
(- thisVal prevVal)
)
)
;;;;;
;; below: not-exposed/"private" functions, used by the "public" functions
;; above.
@ -105,7 +133,7 @@
;; holding true for all calculated numbers. However, this won't fix the first problem if your bank
;; can't do proper maths and manual fixing of transactions will still be required.
;; One problem with the rounding procedure in these three functions is that it is always
;; FIXME: One problem with the rounding procedure in these three functions is that it is always
;; rounding at the second decimal. This works great with dollars and euros and a lot of major
;; currencies but might well cause issues with other currencies not typically divided in 100.
;; I have not tested anything else than dollars.
@ -118,7 +146,7 @@
;; On the opposite side, if you want the automatic rounding but don't understand how to use
;; the cpd_ functions, here is a quick example on how to convert original gnc:Zpmt
;; function calls. The typical setup is to use 'rate/yfreq' as the first parameter, so the
;; slution is to simply use yfreq for both yfreq and ycomp in the gnc:cpd_Zpmt calls, like this:
;; solution is to simply use yfreq for both yfreq and ycomp in the gnc:cpd_Zpmt calls, like this:
;; gnc:pmt( rate / yfreq :nper:pv:fv:type)
;; is equivalent to gnc:cpd_pmt( rate:yfreq:yfreq :nper:pv:fv:type)