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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > http://www.kimvdlinde.com > > > > --------------------------------------------------------------------- > 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]
