commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] financial functions?
Date Tue, 10 Jun 2003 21:36:18 GMT
I 100% agree, I think we should keep such functionality in separate 
modular packages. This is why I think even static access to stats 
functions should not be in MathUtils specifically. Keep each set of 
functionality as separate as possible from an implementation stand 
point. There may come a day in the future when math become more 
modularized and encompass greater functionality, it would be an ugly day 
if there was too much spaghetti code present in the implementation.

-Mark

Tim O'Brien wrote:
> 
> +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. 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message