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 TasksShould be already there?
* Framework and implementation strategie(s) for finding roots or real-valued functions of one (real) variable.
* Cubic spline interpolation.
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
