Interest Calculation Methods

[alloylab]

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

[uruba]

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]

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]

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 😃) 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. 👍

[cjnqt]

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]

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]

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 #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.).