commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [math] API changes for RC2
Date Sun, 26 Sep 2004 03:02:57 GMT
Some thoughts from a general Commons perspective:

1) +0, This is worth getting right early on as package renaming does
tend to confuse users and takes a long time to work through
deprecation etc.
2)  -0. This is a new feature. If it's easy, add it. If it involves
effort, don't bother until 1.1.
3)  -0. Two options leap to mind, release PRNG as it is, or don't
release the PRNG code. Yes it's a pain for users when you change the
functionality in a new version, but when the option is not having a
feature, users opt for the functionality and pain later. Most likely
the change would be a simple perl regexp anyway.
4)  -0. I was never a statistician, but this sounds like new
functionality. Either release the code as is, or drop it. While 3) is
an API change, this sounds like a functional change and those are much
more painful for a user.
5) -0. Keep it as is. Again, it might mean an API change in the
future, but I doubt anyone knows the perfect solution so let's see how
this one goes.

So the only one I'd advise as really being worth the effort is 1. 

Hen

On Sat, 25 Sep 2004 21:41:31 -0400, Kim van der Linde
<kim@kimvdlinde.com> wrote:
> 1) +1 (although I can see that some statistics (like PCA, factorial,
> cluster analysis and so) might end up in a multivariate package).
> 2) +1
> 3) +0 (I can see that it might be more logical to implement it after
> 1.0, but them I would be in favour of dropping PNRG all together in this
> release.)
> 4) +1
> 5) neutral, I can see the rational behind it, but I also see that it is
> not the general way many packages like the java(x) core classes itself
> are made. I can see that there might be good solid reasons (which I do
> not entierly get) to do it that way despite that I personally do not
> like it. But I can live with that.
> 
> Kim
> 
> 
> 
> > The following changes have been suggested recently.  Before cutting 1.0
> > final, we should make sure we are all OK postponing or forgoing these:
> >
> > 1) Eliminate the univariate/multivariate distinction in the stat
> > package, because this seems confusing to some.  Change .univariate to
> > .descriptive and .multivariate to .regression
> >
> > 2) Add methods to create row or column matrices from double arrays and
> > to extract submatrices (to the interface itself, rather than adding
> > these to a utils class later)
> >
> > 3) Make the PRNG fully pluggable in the random package.
> >
> > 4) Modify Variance and StandardDeviation to compute multiple statistics
> > (with the variants being population, rather than sample statistics).
> >
> > 5) Drop the interface / implementation separation throughout the package.
> >
> > I am personally -1 on 4) and 5); -0 on 1) and 2); and +0 on 3). I voted
> > +1 on the release; however, which means that 3) is a wart that I am
> > willing to live with for 1.0.  It can be worked around now and to fix it
> > correctly will require that we define a PRNG interface and introduce
> > factories, etc.
> >
> > Mark, since you voted to reopen API discussion, can you weigh in on
> > these issues and add any others that you see as show-stoppers?
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> --
> http://www.kimvdlinde.com
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message