commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim O'Brien <>
Subject [math] financial functions?
Date Tue, 10 Jun 2003 20:39:39 GMT
Sorry, I've been away for a few days, I'm back.  Will, I think this code
would be really valuable (I'd like to use it myself), we should add it
to a contrib source tree...

On Tue, 2003-06-10 at 08:24, Phil Steitz wrote:
> Al Chou wrote:
> > --- Will Stranathan <> wrote:
> >>Has there been any discussion about the possibility of adding some work to 
> >>Commons somewhere for common financial functions?  

+1 on the idea of having these classes available for use, +1 on
*temporarily* adding this to commons-math, but -1 to adding them to
MathUtils (this code should be stored in a separate contrib source
tree).  Basic Financial utilities would add desired functionality, but
in the "long term" - specific areas of application should not be a part
of commons-math.  I'm not saying this will never be the case, read on...

Alternatively, application areas should be separate modules entirely
(right now, within a separate contrib directory) - we don't want to
create a monolithic collection of code (or a monolithic community of
developers), but in the short-term I can see that adding these limited
utilities would encourage active community participation.  In other
words, +1 for this if and only if we promise to keep these things
limited to very simple applications/algorithms.  

I'd rather not see us start to get into too much specialization (not
that I'm not interested) - IMO commons-math is similar to
commons-digester.  Commons Digester provides a basic mechanism for
executing a set of rules, these rules are triggered by the structure of
an XML file.  Because commons-digester remains focused on a very limited
set of goals, it is a utility which can be used for a wide range of
applications - from marshalling/unmarshalling to/from XML, to a basic
MathML engine, One could even write some sort of programming language
using Digester.....  The point is that Digester is a very generic piece
of code.   Likewise with the Linux kernel.  Strength through simplicity.

We should define the limits of the project and resist the urge to exceed
those boundaries.  This will lead to more nimble and focused
communities, and it will reduce risk.  I've been following the
discussions surrounding the Struts 1.1 RC2 release, and I think that it
might be wise to draw bold boundaries around a project.  Commons-math is
X, and if anything falls outside of X we can add it as a contrib, but I
don't want to open up a Pandora's Box on a sandbox component that hasn't
made it through the promotion process yet.   Also, if a package in
contrib isn't passing 100% of the tests, it isn't a blocker for a
release, AND we could distribute those classes separately (think ant.jar
and optional.jar in Apache Ant).

If someone starts offering Apache utilities for Financial calculations,
then why not start adding code for:  Radioactive Decay, Monte Carlo
simulations, Utilities for the calculation of gambling odds, Circuit
simulation, Aerodynamics, Optimization algorithms for the layout of a
Printed Circuit Board, Quantum Physics, Calculations performed in
Maritime Navigation, etc....

The goal is to release a simple, focused commons-math - get something
through promotion, and either at promotion time or afterwards a
conversation should be started about future direction.  I think we've
got a good amount of community-building to get through first.   Add the
code to a "contrib" source tree. 

> >>Some of the functionality that I'm thinking about is things like:
> >>- Number of periods to bring an annuity to a target value (or pay off a loan

> >>- i.e., NPER)
> >>- Calculation of interest and principal for current payment
> >>- Amortization schedules
> >>- Minimum payment amount calculations, given an interest rate, principal, 
> >>desired payoff date, etc.
> >>
> >>Let me know if there's enough interest for me to put together a proposal (or

> >>if this need is already met elsewhere).

> > Sounds like a good idea to me, I'd say go ahead with the proposal.
> I agree.  Or just submit patches to MathUtils and we can discuss 
> splitting things out as necessary down the road.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message