commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] financial functions?
Date Tue, 10 Jun 2003 21:46:30 GMT

--- "O'brien, Tim" <> wrote:
> 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. 
Well, I can't really argue with the "focus" argument above, since I have been
repeating the same thing from the beginning.  The problem in this specific case
is that what could naturally "belong" in MathUtils is a set of simple functions
for dealing with solving equations involving exponential growth and decay
models.  The vast majority of practical applications of this stuff would be to
financial calulations and it would be most convenient for the users not to have
to know that exponentials were involved at all.  So...if we were to add the
"pure" math stuff to MathUtils, it would not be used much, since as Al has
pointed out, there's not much going on beyond exp(), pow(), log(), etc.  What
would be really interesting/useful is the actual financial applications, but I
now agree with you that this is starting down a slippery slope to add them to
the commons-math package itself.  Therefore, I am

+1 for adding simple financial computations to contrib and following the idea
that you have outlined above for adding "applications" modules via contrib. 

+1 for descoping "exponential growth and decay models" from initial
commons-math release.

P.S.:  struts 1.1 RC2 did ship after all ;-) What caused the most pain at the
end was actually commons dependencies (esp. dbcp -- eventually abandoned -- and
Martin Cooper having to handle FileUploader all by himself), not struts scope,
IMHO.  But your main point is well taken.  We need to keep defining and
maintaining boundaries.


Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).

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

View raw message