commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim van der Linde <>
Subject Re: [math] API changes for RC2
Date Sun, 26 Sep 2004 03:19:28 GMT
Population variance and sample variances do only differ in the number 
the summed difference (second moment) is divided through. The way I have 
implemented it in my Variances class is by keeping the methods as they 
are (I do believe setting the default to sample variances is right) and 
supplement with the general versions, in which you can add a constant like:

final static int Variance.POPULATION = 0;
final static int Variance.SAMPLE= 1;

the internal formulas becomes then:

     public double getResult(final int varianceType) {
             if ((moment.n-varianceType) <= 0) {
                 return Double.NaN;
             } else if (moment.n == 1) {
                 return 0d;
             } else {
                 return 	moment.m2 /
			((double) moment.n - varianceType);

     public double getResult() {
     	return getResult(VarianceTypes.SAMPLE);


Henri Yandell wrote:

> Just to enhance my 4) bit, I'd advise dropping in this case and not
> releasing this code if you plan to change the internal functionality.
> If it's going to involve an API change with the new code though, go
> ahead and release.
> Hen
> On Sat, 25 Sep 2004 23:02:57 -0400, Henri Yandell <> wrote:
>>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.
>>On Sat, 25 Sep 2004 21:41:31 -0400, Kim van der Linde
>><> 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
>>>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.
>>>>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?
>>>>To unsubscribe, e-mail:
>>>>For additional commands, e-mail:
>>>To unsubscribe, e-mail:
>>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


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

View raw message