On 12/20/06, Luc.Maisonobe@free.fr <Luc.Maisonobe@free.fr> wrote:
> Selon Phil Steitz <phil.steitz@gmail.com>:
>
> > We have added a lot of new functionality to [math] since the 1.1
> > release, and Mantissa includes quite a bit more. We need a 1.2
> > release plan, incorporating some elements of Mantissa. Here is a
> > straw man  please any and all jump in to comment and most of all
> > volunteer to take on tasks.
> >
> > 1. Start with a list of Mantissa features to introduce into [math]
>
> Agreed. In order to help the choice, here is the complete list of packages
> provided by Mantissa, with my own comments about them :
>
> algebra : univariate polynomials, orthogonal polynomials
> (very basic, straightforward and inefficient implementation)
> estimation : general estimation, least squares,
> GaussNewton, LevenbergMarquardt
> (the package based on interfaces for problems and solvers,
> which should be in a approach similar to commonsmath)
> fitting : general curve fitting, polynomials, harmonic series
> (this is a simple wrapper around estimation, except for
> harmonic fitting which is more complex, but is it useful ?)
> functions : scalar and vectorial functions interfaces definitions
> (was created for the sake of quadrature and fitting, I
> think commonsmath provides something better)
> geometry : vectors and rotation in 3D
> (tiny package, the most important thing is Rotation3D which
> is quite elaborated and whose code is validated in real life
> space applications)
> linalg : linear algebra
> (very basic, straightforward, inefficient and incomplete
> implementation)
> ode : Ordinary Differential Equation
> (this this the most important and polished package, most
> Mantissa users downloaded it only for this package which is
> is quite elaborated, provides state of the art algorithm with
> all bells and whistles like continuous output, multiple
> switching functions supporting Gstop and discontinuities,
> integration driven in slave or master mode ...)
> quadrature : functions quadrature, Riemann, Trapezoid, enhanced Simpson, Gauss
> (classical package, use the function package)
> random : random generators and basic statistics
> (to be compared with commonsmath)
> roots : simple root finding
> (only a Brent implementation)
>
> > 1.2, based on the WishList and review of the Mantissa code base. Here
> > is my suggested list for math 1.2:
> > a. The entire Mantissa estimation package
> > b. The entire Mantissa optimization package
>
> I would strongly suggest to add also the ode and geometry packages.
>
OK  I suggested starting with the ones above only because they looked
pretty consistent with the commonsmath design approach and quite
honestly are the ones I have looked most closely at. I agree that the
others are very useful and should come in. I just thought we might
want to limit scope for 1.2. Based on your comments, I say lets add
geometry and ode to 1.2. We can look at algebra, et al for subsequent
releases.
> > 2. Repackage and refactor Mantissa code  not much, actually  to be
> > consistent with the rest of [math] (interface encapsulation, pluggable
> > implementations using new approach  see 5 below)
>
> Agreed. I also think some work needs to be done to merge error handling.
> Mantissa provides a way to localize messages, it could be a useful addition to
> commonsmath.
>
+1  that is a weakness in [math] now. We just have to be careful
about backward compatibility until we bump to 2.0.
> > 3. Replace suboptimal implementations in math random and analysis
> > packages with better impls in Mantissa, where this makes sense (TBD 
> > comments / suggestions welcome). Also, leverage relevant bits and code
> > recently contributed in MATH157 to implement SVD.
>
> I'm not sure Mantissa has more optimal implementations :( I am not a
> statistician and only implemented what I needed for my own work. I never had
> any feedback on these parts.
>
Let's take a close look and see. I will look carefully at the random
stuff. Can you pick up the thread on SVD?
> > 4. Clean up things added to math trunk since 1.1
> >
> > 5. Replace commonsdiscovery dependency injection mechanism with
> > springcompatible approach  patches welcome!
>
> I don't have a sufficient knowledge on commonsmath yet to have an opinion on
> these tasks.
Have a look at, e.g. the distributions package. We use an abstract
factory pattern there that allows implementations to be plugged in
dynamically at run time. We use commonsdiscovery as the mechanism
for configuring what concrete implementation to load at runtime. I am
suggesting that we provide support for dependency injection via
spring. We can hold off on this if there is not sufficient interest.
I just thought I would suggest it and see if there was.
>
> > 6. Get to zarro boogs (or a pretty Jira screen, I guess ;)
>
> Yes :)
>
> > Comments, volunteers, patches, welcome!
>
> I can do all Mantissa refactoring tasks to merge it into the main tree once the
> merged parts are chosen.
>
> I would suggest to perform step 2 in Phil's proposal starting with error
> handling, followed by packages renaming, followed by interfaces refactoring.
>
+1  just remember we need somehow to maintain backward compatiblity
for the error handling piece. Lets go ahead with {estimation,
optimization, geometry, ode}
Phil

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
