commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: [math] Project Maturity?
Date Mon, 08 Sep 2003 18:38:47 GMT
Mark R. Diggory wrote:
> 3.) Test Coverage.
The coverage report doesn't seem to be available from the jakarta
site. Can I have a look at it somewhere else?

> 4.) Code review.
I just discovered a bunch of printStackTrace() in BeanTransformer.
Any ideas how this should be handled in a better way? Throwing
a MathException?

> Algorithm Development Tasks
>         * Framework and implementation strategie(s) for finding roots or 
> real-valued functions of one (real) variable.
>         * Cubic spline interpolation.
Should be already there?

Additions:
- Find a way to make [math] compile and run under JDK 1.3 again.
  This mainly consists of deriving the exceptions from [lang]
  NestableException and adding a GUMP/Maven dependency on [lang].
- Clean up and unify exceptions. The ConvergenceException thrown
  in ContinuedFraction is a runtime exception not derived from
  MathException. The issues here:
   + Root finding should throw a ConvergenceException in case of
     convergence problems (falling out of the loop without
     decreasing the interval enough). However, because the
     exception is not derived from MathException, it must be
     handled separately by callers if this is done so.
   + Deriving ConvergenceException from the checked MathException
     would add a lot of throws clauses. This seems to be justified
     for the relative complex ContinuedFraction, but unfortunately
     this is used in the gamma function, where throwing a checked
     exception may throw off people (but then, java.io throws the
     checked IOException even for close()).
  This has been discussed in general terms, but without a conclusion
  for our specific case.
- Make the default root finder run time configurable again. Well,
  if necessary.
- I'd like to refactor the linear equation solving a bit, adding
  a new class for the matrix decomposition so that solvers can
  be written which can take advantage of special matrix forms
  (e.g. symmetric or tridiagonal). As usual, time is lacking.
- The "internal data exposure issue" in RealMatrix and in the
  interpolator has to be discussed and resolved. See the comment
  in the interpolator class for details.
- Possibly get rid of RootFinding in favor of moving the
  functionality to UnivariateRealSolverUtil? Dunno.
- Rename UnivariateRealSolverUtil to UnivariateRealSolverUtils?
- Rename UnivariateRealSolverImpl to UnivariateRealSolverSPI?
- It has been already discussed but can't we load off DoubleArray
  and related classes to [collections] or the new [pcollections]?

J.Pietschmann


Mime
View raw message