[math] Re: "Straw man" release plan

[Piotr Kochañski]

Hello

> Ah, now I understand what you have been trying to communicate and I agree
> that adding all of this functionality to EmpiricalDistribution is not a
> good idea.  I was only considering the simple use case modelling the
> sampling distribution of a single, known statistic.  The more general case
> in which the boostrap samples are leveraged for inferences about multiple
> statistics will require more complex machinery.  I suggest that we take
> this up again post 1.0.  For now, I don't think it makes sense to
> significantly modify EmpiricalDistribution (though given the confusion, it
> might be better to change the name :-)

No, no, the name is OK. The purpose of the EmpiricalDistribution is quite
obvious
and it really describes EDF. Now I have clear view what is
EmpiricalDistribution 
for and, what even more important, what is it *not* for.

I will patch EmpiricalDistribution with the load(double[]) method soon
(such
initialization would be quite usefull regardless of bootstrap, etc.)

Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Re: "Straw man" release plan

[Phil Steitz]

--- Piotr Kochañski <[EMAIL PROTECTED]> wrote:


> > My thought was that we could do some things (e.g. estimate confidence 
> > intervals) without storing the boostrap samples or even the full set of
> 
> > bootstrap statistics.
> 
> This is not a problem at all. When we initialize EmpiricalDistribution
> using load(...) method, we can calculate what we want - we have
> data set at that moment. 
> 
> The problem I see is that we have to a priori specify for which
> statistics
> (bootstrap) confidence interval or standard error would be calculated. 
> 
> We should not make that decision for the user, so some configuration of 
> EmpiricalDistribution object would be necessary, e.g.
> 
> load(double[][], UnivariateStatistics[]) 
> 
> then all the interesting calculation would be done for provided 
> UnivariateStatistics. The default choice could be just SummaryStatistics:
> load(double[][]){
>statisticsToBeBootstrapped[] = All SummaryStatistics
> }
> 
> If bootstrap samples are not provided, e.g. user uses other
> load function, we can provide confidence intervals based on the
> normal distribution assumption (for those statistics, for which
> it can be calculated).
> 
> In fact we could leave the choice which summary statistics should
> be calculated to the user at all (e.g. for performance reason - someone
> would never be interested in calculating some statistics, but it is done
> anyway, which slows down initialization of the object).
> 
> load(String, UnivariateStatistics[]) etc.
> 
> Then present getSampleStats() method should return
> an object which enables access to calculated statistics and/or
> the confidence intervals for them.
> 

Ah, now I understand what you have been trying to communicate and I agree
that adding all of this functionality to EmpiricalDistribution is not a
good idea.  I was only considering the simple use case modelling the
sampling distribution of a single, known statistic.  The more general case
in which the boostrap samples are leveraged for inferences about multiple
statistics will require more complex machinery.  I suggest that we take
this up again post 1.0.  For now, I don't think it makes sense to
significantly modify EmpiricalDistribution (though given the confusion, it
might be better to change the name :-)

Phil

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] Re: "Straw man" release plan

[Piotr Kochański]

Mark R. Diggory wrote:


> 
> 
> I think maybe this should be returning the more generic 
> StatisticalSummary interface. If you are returning precalculated 
> results, you do not exactly want to expose the underlying implementation 
> to modification by the user.
> 
> StatisticalSummary[] sampleStats ...

That's good idea
 

> If your going to be preserving the original/bootstrap values in a 
> double[][], then the Standard "DescriptiveStatisticsImpl" could be used.
> 
> public interface FullStatisticalSummary {
>   public abstract double getMean();
>   public abstract double getVariance();
>   public abstract double getStandardDeviation();
>   public abstract double getMax();
>   public abstract double getMin();
>   public abstract long getN();
>   public abstract double getSum();
>   public abstract double getPercentile(double p);
>   ...
> }
> 
> or more simply,
> 
> public interface FullStatisticalSummary extends StatisticalSummary{
>   public abstract double getPercentile(double p);
>   ...
> }

Exactely, but the point is that we have to preserve original/bootstrap
values and EmpiricalDistribution is not storing them - internally it keeps
data
in the array of bins. As I understand this was the aim - we don't have to
keep the whole data set in order to get important information about the
empirical distribution.  If a data set is huge this is a true gain.

If, on the other hand, I want to keep the whole data set then I can easily
use
other tools to calculate any statistics I want so I don't need to use 
EmpiricalDistribution.

Documentation for EmpiricalDistribution gives two example applications
of this interface - preparing data for drawing a histogram and provide
methods to draw random numbers from such a distribution. I am
wondering if making EmpiricalDistribution responsible for other tasks
like handling bootstrap samples or even doing bootstrap would not
make it to complicated to use.

Piotr


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Re: "Straw man" release plan

[Phil Steitz]

Mark R. Diggory wrote:

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.


I think maybe this should be returning the more generic 
StatisticalSummary interface. If you are returning precalculated 
results, you do not exactly want to expose the underlying implementation 
to modification by the user.
I agree.  That is why StatisticalSummary was created.

Phil







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "Straw man" release plan

[Phil Steitz]

As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.
Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?
No, I was thinking that EmpiricalDistribution could be used to model the 
bootstrap distribution of a statistic directly.  So, e.g., to compute 
bootstrap confidence intervals for a statistic S, the method would be:
1. Compute N values of S based on bootstrap samples.  Call the resulting 
N-length double array sHat[].
2. Load an EmpiricalDisribution using sHat[].
3. Use the percentiles of the EmpiricalDistribution to compute confidence 
intervals (ideally including bias correction. Cf. Efron & Tibshirani, 
_Intro to the Bootstrap_, chs. 13-14).



Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
Yes.  Needed for above.  Patches welcome :-)

2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();
Yes.  It should return a List.

Thanks for the feedback.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Re: "Straw man" release plan

[Mark R. Diggory]

Piotr Kochański wrote:
Hello

Phil Steitz wrote:


Thinking about how this will eventually work, it has occurred to me that 
EmpiricalDistribution could be used to digest / represent bootstrap 
distributions.  Since we want the interface for EmpiricalDistribution to 
be complete for 1.0, we need to make sure that bootstrap data can be 
loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
have been thinking about adding load() methods to EmpiricalDistribution 
that take double[] arrays and streams as values, as well as an addValue() 
method.  Does this make sense?  I would also appreciate any comments / 
patches on how to improve the EmpiricalDistribution interface or 
EmpiricalDistributionImpl.  If refactoring or even holding this from the 
release are in order, I want to make sure that we do it.


As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.


I think maybe this should be returning the more generic 
StatisticalSummary interface. If you are returning precalculated 
results, you do not exactly want to expose the underlying implementation 
to modification by the user.

StatisticalSummary[] sampleStats ...

Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?

The zeroth row of every matrix could be reserved for original
sample and the rest for bootstrapped results (if they can be
calculated, i.e. samples are given). This can be achieved but
some effort has to be made to make it simple to use for those,
who does not care about bootstrap and want to get results
based only on the original sample. 

The other thing is that such an extension would be very
usefull as long as we play with such bootstrap algorithms,
which use those statistics which are memebers of SummaryStatistics.
Often this is not the case (classic example is Median or Trimmed Mean,
which is not among SummaryStatistics). Sometimes it is also
necessary (or more comfortable) to operate on the raw bootstrap
samples, not EDF calculated from those samples. In this two
cases bootstrap embeded into EmpiricalDistribution would not
be that useful.
If your going to be preserving the original/bootstrap values in a 
double[][], then the Standard "DescriptiveStatisticsImpl" could be used.

public interface FullStatisticalSummary {
public abstract double getMean();
public abstract double getVariance();
public abstract double getStandardDeviation();
public abstract double getMax();
public abstract double getMin();
public abstract long getN();
public abstract double getSum();
public abstract double getPercentile(double p);
...
}
or more simply,

public interface FullStatisticalSummary extends StatisticalSummary{
public abstract double getPercentile(double p);
...
}
Which would then Be implemented by DescriptiveStatistcs.

If returning an Interface that exposes the statistical analysis of said 
values, then an expanded interface that includes other available 
statistics could easily be added to the API.



Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();

although I can't imagine practical situation, where other List then
ArrayList would be better.
Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] Re: "Straw man" release plan

[Piotr Kochański]

Hello

Phil Steitz wrote:

> Thinking about how this will eventually work, it has occurred to me that 
> EmpiricalDistribution could be used to digest / represent bootstrap 
> distributions.  Since we want the interface for EmpiricalDistribution to 
> be complete for 1.0, we need to make sure that bootstrap data can be 
> loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
> have been thinking about adding load() methods to EmpiricalDistribution 
> that take double[] arrays and streams as values, as well as an addValue() 
> method.  Does this make sense?  I would also appreciate any comments / 
> patches on how to improve the EmpiricalDistribution interface or 
> EmpiricalDistributionImpl.  If refactoring or even holding this from the 
> release are in order, I want to make sure that we do it.

As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.

Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?

The zeroth row of every matrix could be reserved for original
sample and the rest for bootstrapped results (if they can be
calculated, i.e. samples are given). This can be achieved but
some effort has to be made to make it simple to use for those,
who does not care about bootstrap and want to get results
based only on the original sample. 

The other thing is that such an extension would be very
usefull as long as we play with such bootstrap algorithms,
which use those statistics which are memebers of SummaryStatistics.

Often this is not the case (classic example is Median or Trimmed Mean,
which is not among SummaryStatistics). Sometimes it is also
necessary (or more comfortable) to operate on the raw bootstrap
samples, not EDF calculated from those samples. In this two
cases bootstrap embeded into EmpiricalDistribution would not
be that useful.

Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();

although I can't imagine practical situation, where other List then
ArrayList would be better.

Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "Straw man" release plan

[Piotr Kochański]

Phil Steitz wrote:

> Thinking about how this will eventually work, it has occurred to me that 
> EmpiricalDistribution could be used to digest / represent bootstrap 
> distributions.  Since we want the interface for EmpiricalDistribution to 
> be complete for 1.0, we need to make sure that bootstrap data can be 
> loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
> have been thinking about adding load() methods to EmpiricalDistribution 
> that take double[] arrays and streams as values, as well as an addValue() 
> method.  Does this make sense?  I would also appreciate any comments / 
> patches on how to improve the EmpiricalDistribution interface or 
> EmpiricalDistributionImpl.  If refactoring or even holding this from the 
> release are in order, I want to make sure that we do it.

As I understand load(double[][]) would compute Empirical Distribution
Function for every bootstraped sample (provided from some other source).
Then, instead of having 

SummaryStatistics sampleStats

we should provide 

SummaryStatistics[] sampleStats

where this array would contain SummaryStatistics calculated
for every sample.  SummaryStatistics getSampleStats() would
be changed as well.

Similarly other methods/objects in EmpiricalDistribution  
would have to be modified (e.g. binStats would have to be 
an array of ArrayLists, etc.).

Do I get your intentions right?

The zeroth row of every matrix could be reserved for original
sample and the rest for bootstrapped results (if they can be
calculated, i.e. samples are given). This can be achieved but
some effort has to be made to make it simple to use for those,
who does not care about bootstrap and want to get results
based only on the original sample. 

The other thing is that such an extension would be very
usefull as long as we play with such bootstrap algorithms,
which use those statistics which are memebers of SummaryStatistics.

Often this is not the case (classic example is Median or Trimmed Mean,
which is not among SummaryStatistics). Sometimes it is also
necessary (or more comfortable) to operate on the raw bootstrap
samples, not EDF calculated from those samples. In this two
cases bootstrap embeded into EmpiricalDistribution would not
be that useful.

Two comments concerning EmpiricalDistribution 
1. Probably it would be nice to have load(double[]) method
2. Instead of
   ArrayList getBinStats();
there could be 
   List getBinStats();

although I can't imagine practical situation, where other List then
ArrayList would be better.

Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] Re: "Straw man" release plan

[Phil Steitz]

Piotr Kochan'ski wrote:
Hello,



2. Use Mark's magical maven release-generator to cut a 1.0-B1 release 
including everything currently in CVS other than the /experimental tree.
(Confidence intervals, the Bootstrap and Multiple Regression will have to 
wait until 1.1.)


As I understand, math is now in a freezed state and it is better not
to submit any new code (except of that, which is needed to have
1.0 ready obviously)? 
"Frozen" is a bit strong.  My preference would be to hold off on 
confidence intervals and the bootstrap until we get 1.0 out.  I suppose we 
could add the bootstrap by itself, but I think it would be better to add 
it as part of a more general solution for resampling-based inference (incl 
non-parametric conf. intervals) and that will require some discussion.

Thinking about how this will eventually work, it has occurred to me that 
EmpiricalDistribution could be used to digest / represent bootstrap 
distributions.  Since we want the interface for EmpiricalDistribution to 
be complete for 1.0, we need to make sure that bootstrap data can be 
loaded into EmpiricalDistribution conveniently (if this makes sense), so I 
have been thinking about adding load() methods to EmpiricalDistribution 
that take double[] arrays and streams as values, as well as an addValue() 
method.  Does this make sense?  I would also appreciate any comments / 
patches on how to improve the EmpiricalDistribution interface or 
EmpiricalDistributionImpl.  If refactoring or even holding this from the 
release are in order, I want to make sure that we do it.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] Re: "Straw man" release plan

[Piotr Kochański]

Hello,


> 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release 
> including everything currently in CVS other than the /experimental tree.
> (Confidence intervals, the Bootstrap and Multiple Regression will have to 
> wait until 1.1.)

As I understand, math is now in a freezed state and it is better not
to submit any new code (except of that, which is needed to have
1.0 ready obviously)? 

I have some bootstrap and standard error code ready, but I guess 
it's better to wait with submission until 1.0 will be out.

Piotr

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] "Straw man" release plan

[Mark R. Diggory]

Brent,

Welcome, we have been creating documentation on th developer process. 
its probably best you read through it and then talk with us more.

http://jakarta.apache.org/commons/math/developers.html

1.) Specifically focus on the areas of working with ant, maven, cvs, 
creating patches and submitting them via bugzilla. This is how you make 
your first steps in the contributor/commiter process

2.) What your development environment at this time? Ant and Maven work 
good for testing/building. I'd recommend eclipse for its ant, cvs and 
refactoring capabilities, plus its free. www.eclipse.org

3.) Post lots of questions on the list. Get involved with the 
discussions on RealMatrix related stuff.

Cheers
-Mark
Brent Redeker wrote:

Hello everybody,

My name is Brent Redeker, and I've had some interest in the Commons Math 
project since I heard of it about a month ago. I've been meaning to 
offer any help I can give to the project, and perhaps I can be of some 
assistance in preparing for a 1.0 release. If the project could use my 
help, and if somebody could get me started, I'd be glad to do what I 
can. (Unfortunately, I'll probably need some hand-holding at first, as I 
am unfamiliar with how Apache contributors work.)

I'm actually kind of interested in the Commons Math linear package, as 
that seems like it needs some work yet. Although I haven't finished my 
degree yet, I've had a number of mathematics courses, including Linear 
Algebra and Numerical Analysis, so I'm sure I know enough to be of some 
use.

Brent Redeker

On Jan 30, 2004, at 8:58 AM, Phil Steitz wrote:

After reviewing

I agree with Mark that we should be aiming for a 1.0 release of [math].
Here is a "straw man" plan, with lots of detail missing.

1. Complete the following code / doco tasks

a. Finish the User Guide
b. Finalize and execute RealMatrix solve() strategy
c. Finalize and execute spline changes
d. Extend certified data tests with tests against R or other sources 
(need to finalize what is included here)
e. Fix broken links and other errors in javadoc
f. Improve path and boundary value test coverage
g. Finalize and implement "BeanList" stats

2. Use Mark's magical maven release-generator to cut a 1.0-B1 release 
including everything currently in CVS other than the /experimental tree.
(Confidence intervals, the Bootstrap and Multiple Regression will have 
to wait until 1.1.)

3. Depending on feedback from B1, proceed either to B2... or RC1... 
then 1.0 final.

Am I missing anything?  Are there other things that we think really 
*must* get into 1.0?  Are there things that we should omit?

Mark, do you want to play the Release Manager role?  If not, I am 
willing to do it.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] "Straw man" release plan

[Mark R. Diggory]

Phil,

I've added some issues I want to address in the release process, if you 
wish to take on the RM roles associated with 1, I think we would be honored.

-thx,
Mark
Phil Steitz wrote:

After reviewing

I agree with Mark that we should be aiming for a 1.0 release of [math].
Here is a "straw man" plan, with lots of detail missing.

1. Complete the following code / doco tasks

a. Finish the User Guide
b. Finalize and execute RealMatrix solve() strategy
c. Finalize and execute spline changes
d. Extend certified data tests with tests against R or other sources 
(need to finalize what is included here)
e. Fix broken links and other errors in javadoc
f. Improve path and boundary value test coverage
g. Finalize and implement "BeanList" stats

2. Use Mark's magical maven release-generator to cut a 1.0-B1 release 
including everything currently in CVS other than the /experimental tree.
(Confidence intervals, the Bootstrap and Multiple Regression will have 
to wait until 1.1.)

  a. Add a a preGoal for dist to make sure the generated user guide html
 gets into the distributions.
  b. Remove experimental directory from binary distribution, think this
 was just a build error
  c. create manifest entries for jars.
  d. create INSTALL readme for src distribution (bulding instructions
 for ant and maven)
  e. iron out details of tagging repository when release is cut with
 maven
3. Depending on feedback from B1, proceed either to B2... or RC1... then 
1.0 final.

Am I missing anything?  Are there other things that we think really 
*must* get into 1.0?  Are there things that we should omit?

Mark, do you want to play the Release Manager role?  If not, I am 
willing to do it.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] "Straw man" release plan

[Brent Redeker]

Hello everybody,

My name is Brent Redeker, and I've had some interest in the Commons 
Math project since I heard of it about a month ago. I've been meaning 
to offer any help I can give to the project, and perhaps I can be of 
some assistance in preparing for a 1.0 release. If the project could 
use my help, and if somebody could get me started, I'd be glad to do 
what I can. (Unfortunately, I'll probably need some hand-holding at 
first, as I am unfamiliar with how Apache contributors work.)

I'm actually kind of interested in the Commons Math linear package, as 
that seems like it needs some work yet. Although I haven't finished my 
degree yet, I've had a number of mathematics courses, including Linear 
Algebra and Numerical Analysis, so I'm sure I know enough to be of some 
use.

Brent Redeker

On Jan 30, 2004, at 8:58 AM, Phil Steitz wrote:

After reviewing

I agree with Mark that we should be aiming for a 1.0 release of [math].
Here is a "straw man" plan, with lots of detail missing.

1. Complete the following code / doco tasks

a. Finish the User Guide
b. Finalize and execute RealMatrix solve() strategy
c. Finalize and execute spline changes
d. Extend certified data tests with tests against R or other sources 
(need to finalize what is included here)
e. Fix broken links and other errors in javadoc
f. Improve path and boundary value test coverage
g. Finalize and implement "BeanList" stats

2. Use Mark's magical maven release-generator to cut a 1.0-B1 release 
including everything currently in CVS other than the /experimental 
tree.
(Confidence intervals, the Bootstrap and Multiple Regression will have 
to wait until 1.1.)

3. Depending on feedback from B1, proceed either to B2... or RC1... 
then 1.0 final.

Am I missing anything?  Are there other things that we think really 
*must* get into 1.0?  Are there things that we should omit?

Mark, do you want to play the Release Manager role?  If not, I am 
willing to do it.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[math] "Straw man" release plan

[Phil Steitz]

After reviewing

I agree with Mark that we should be aiming for a 1.0 release of [math].
Here is a "straw man" plan, with lots of detail missing.

1. Complete the following code / doco tasks

a. Finish the User Guide
b. Finalize and execute RealMatrix solve() strategy
c. Finalize and execute spline changes
d. Extend certified data tests with tests against R or other sources (need 
to finalize what is included here)
e. Fix broken links and other errors in javadoc
f. Improve path and boundary value test coverage
g. Finalize and implement "BeanList" stats

2. Use Mark's magical maven release-generator to cut a 1.0-B1 release 
including everything currently in CVS other than the /experimental tree.
(Confidence intervals, the Bootstrap and Multiple Regression will have to 
wait until 1.1.)

3. Depending on feedback from B1, proceed either to B2... or RC1... then 
1.0 final.

Am I missing anything?  Are there other things that we think really *must* 
get into 1.0?  Are there things that we should omit?

Mark, do you want to play the Release Manager role?  If not, I am willing 
to do it.

Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]