commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] freezing current state for release ?
Date Sun, 05 Jul 2009 16:57:26 GMT
Luc Maisonobe wrote:
> Hello all,
> I am still struggling to implement properly an efficient Backward
> Differential Formulas (BDF) integrator for stiff problems in the ODE
> package, to solve MATH-172. I fear I won't be able to finish this soon.
> As the release of 2.0 is now mostly blocked by this issue, I would
> propose to postpone it to 2.1, as well as MATH-194 and MATH-195 which
> are not major ones. Do you agree with this ?
> The other remaining issues are MATH-261 concerning generics in Frequency
> and MATH-224 concerning aggregate statistics.
> I have tried some workarounds to remove the 7 warnings I get in
> Frequency (3 concerning use of raw types, 4 concerning type safety). I
> did not succeed in reducing the number of warnings, I only moved them
> around or even increased the number. Does someone smarter than me have a
> clue to finish this or do we close the issue with the current state,
> which is much better than what we had a few months ago ?
I am OK with the s/Object/Comparable change sebb suggested a while 
back.  If that improves things significantly, we should go ahead with 
it.  Otherwise, I am fine leaving as is.
> Concerning aggregate statistics, is the current state stable enough or
> do we need more work on this ?
I think the current code is stable enough, but I have to confess to some 
second thoughts on the approach and I have  been working on an 
alternative using static methods that take StatisticalSummaryValues 
rather than stats themselves and just compute the aggregated values.  
This has the advantage of working much better in distributed 
envirionments and eliminating the need for synchronization (which could 
kill performance).  I will complete this in the next couple of days, 
commit and we can decide.
> I would really much like to have 2.0 out soon now.

The other thing that I have been on the fence about is the multiple 
regression API in general and the GLSMultipleLinearRegression 
implementation.  The latter has a naive implementation that I have not 
had cycles or itch to fix.  I would appreciate some more eyeballs on 
this and opinions on whether we should hold it or release it.  Same with 
API in general, which is missing quite a few things (OK for first 
release), but may be overly complex - especially if we drop the GLS 
class.  Suggestions for improvement are welcome.

> Luc
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message