J.Pietschmann wrote:
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?
Is this something we don't have setup properly in maven?
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?
Yes, that would probibly be better. I would have the transformer method in NumberTransformer actually throw a MathException and construct the MathExceptions in BeanTransformer to include the exception as the cause
throw new MathException(e.getMessage(),e);
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?
Thats what needs to get reviewed, I know somethings were completed without the task list getting updated, we need to make sure we are in sync.
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].
why is this required to run under 1.3? (stupid me I wasn't paying attention to that discussion...) The dependency on lang and NestableException makes sense to me in and of itself.
- 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.
Writing the framework would probibly be easier then implementing the solvers, if the framework can be put in place before release 1.0, then more solvers could be added in minor releases.
- 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.
Ok,
- 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]?
I've thought about this, I'm concerned with the uncertainty of where these primitive collections are going to land. I suspect we should wait until that stablizes.
There's always going to be room to improve on this stuff, I want to see a more producitve release schedule once we get out of the sandbox, don't expect that just because something doesn't go into 1.0 that it'll be a year or so before it shows up in the next release. I'd like to see incremental releases on a stable schedule.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
