search

uruba / FinanCalc

:moneybag: A lightweight, simple and easy PHP library for calculating annuities (e.g., mortgages) and other financial instruments according to various input data
The Unlicense
30 stars 6 forks source link

Interest Calculation Methods #2

Open alloylab opened 8 years ago

alloylab commented 8 years ago

Any plans to add support for different types of interest calculation methods? 360 / 360 365 / 360 365 / 365 etc.

uruba commented 8 years ago

Hello, yes, this has certainly been on the radar for some time now. I however cannot promise when I will finally get around to implementing it.

alloylab commented 8 years ago

well if you want some help more than willing to pitch in, just need to agree on how implement my thought is to rename the function newMonthlyDebtAmortization to newMonthlySimpleDebtAmortization and newMonthlyComplexDebtAmortization... simple being the current method and complex being alternative interest calculation methods. If we are going to move forward this, I would also like to support for loans with ballons

uruba commented 8 years ago

The initial thought as to how to handle this was to have a convention defined (and selected) in the global settings file, with the possibility to override it through optional arguments of concerned methods (so that the setting doesn't have to be changed in case there's a need to work with multiple conventions within a single application). So basically a concept compatible (if not the exact same thing :smiley:) with what you suggest.

It's a good idea to distinguish the "simple" and "complex" methods in their name to be obvious at a glance but here I'd rather tackle it with something like an optional method argument, because otherwise it would make already long and convoluted method names even more complex (this is a problem with many methods and class members, though curtailing the names would detract from clarity).

Support for loans with balloon payments can be added, noting it down. :+1:

cjnqt commented 8 years ago

Great project!

I think an optional method argument is a good solution, then it is possible to implement different methods of amortization the future: 

newMonthlyDebtAmortization(40000, 60, 0.12, LINEAR) // straight linear amortization
newMonthlyDebtAmortization(40000, 60, 0.12, ANNUITY) // current implementation
newMonthlyDebtAmortization(40000, 60, 0.12, BULLET) // all at once, paid on the last period
etc...
alloylab commented 8 years ago

I agree with optional argument. Below are all the different interest calculation types I think we should include. Last few are rare. If you know of any others please add to the list.

30/360 - Most Common... default? 30/365 actual/360 actual/365 360/365 365/365 365/360

uruba commented 8 years ago

Yes, I think we should include at least the most used ones, but of course the more the better. I've found this list at the webpage of SAP company. Wikipedia also has a nice article on this that I think can be used as a starting point.

And as for the https://github.com/uruba/FinanCalc/issues/4, @cjnqt demonstrated nicely the thought behind the optional argument (which can be represented, for example, by an enum, like it already is with some of the identifiers – e.g. the "payment" or "value" type of an annuity, etc.).