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