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] Project Maturity?
Date Mon, 08 Sep 2003 20:23:27 GMT


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


Mime
View raw message