Phil Steitz wrote:
No, an array is not a mathematical object.
If you are a purist, yes, but for many people, they are roughly equivalent.
Here again, the point is that the math object should expose properties consistent with its definition -- like any other Java object. What is actually wrong here is to expose the double[][] and double[] properties. This was done for efficiency and is what is causing the confusion.
Well, in that case, eliminate all those and make a double[][] based equivalent for easy calculations, but the current situation is that the user has continiously to track were (s)he has to use the 1 based system, and were the 0 based system. And cast back and forth while using so.
Well, for the classes that I build, I need them all the time. And so, itYes, this is the point above. My experience working with matrices in Java and other languages, however, is that there are times when you need to efficiently get at the data. Tnat is why the double[][]-valued methods were provided. These should be rarely used.
is highly inefficient for me to use this package as curently implemented. I think I can better use JAMA or the GMatrix in de 3d api from SUN because I can work with those, contrary to this package.
We can easily add a PopulationVariance statistic, which is the right way to handle this, as it is a different statistic. The UnivariateStatistic interface and framework was designed to support this kind of thing. I do not see the need to hold the release for this.
I do see the benifit of having it integrated into one single class, in wich the default is the sample (co)variances, and the others can be invoked specifically.
- BivariateRegression (Should be in univariate or in a new package bivariate, and called LSRegression. I only today realized that is was the Least square regression because of its confusing name and location.
Did you look at the javadoc?
Yes.
The term "bivariate regression" is more or less standard in (elementary) statistics and is used to distinguish the 2-variable case from the case where there are multiple independent variables, which is usually called "multiple regression."
Well my experience is that the bivariate is often used to distinguish a regression with two indepenent variables from the ones with one independent variable.
Since bivariate regression involves 2 variables, it belongs in the multivariate package. The univariate package is for statistics involving just one variable. This is also consistent with standard statistical terminology.
Well, I probably had other textbooks than you.....
And I guess the SAS guys have it wrong also than....:
http://v8doc.sas.com/sashtml/stat/chap65/sect39.htm
(O, google gives over 4000 hits for "univariate regression" back, http://www.google.com/search?q=%22Univariate+regression%22 )
And I guess that the covariance class should be included in the multivariate package?
There are indeed lots of different kinds of bivariate regression models that can be fit. BivariateRegression estimates the most common among these, ordinary least squares regression. I suppose we could call it "LeastSquaresBivariateRegression", but that is a bit long and since OLS is the most common model, I think it is fine to keep the name as it is. I would expect us to do the same thing, btw, when we add support for Multiple Regression (use the "MultipleRegression" name for the OLS version) All of this is specified in the javadoc and the user guide.
I am in favor of selfexplaining names, and bivariate is used for both regression with one and two independent variable, so not clear what is meant by it.
- Generally, I find the whole package rather user unfriendly, and feels for me as designed for hard-core mathematicians /programmers.
Did you look at the class javadoc and the user guide?
Yes.
While we do expect users to be Java programmers, we certainly do not expect them to be "hard-core mathematicians."
Well, the longer that I am here, the more it looks like it....
This is one reason that we need to stick to standard and elementary definitions and notation.
Well, to me, this package does not look like that at all. Actually, the more I get to know the package, the less I like it because of what I experience as deviations from the ordinary.
If we have not succeeded in keeping things simple, we are certainly open to improving documentation and / or providing wrappers or simplified interfaces. If you have specific examples / suggestions for improvement, please share these. We want to make the package as easy to use a possible, while still maintaining extensibility.
Well, I have indicated several things already, but all of them are put aside as "standard notation" or related arguments....
Kim
-- http://www.kimvdlinde.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
