Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <414E53A5.1020103@kimvdlinde.com>
Date: Sun, 19 Sep 2004 23:51:01 -0400
From: Kim van der Linde <kim@kimvdlinde.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [VOTE] Release Math 1.0
References: <414DEE71.10508@steitz.com> <414E2F44.3050009@kimvdlinde.com>
 <414E3844.2050108@steitz.com> <414E3E15.6060702@kimvdlinde.com>
 <414E2464.2070907@steitz.com>
In-Reply-To: <414E2464.2070907@steitz.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Phil,

Phil Steitz wrote:
>> the regression, which is still in the wrong package.
> 
> We discussed this and concluded that it did not make sense to combine
>  univariate and multivariate statistics into one package and by any 
> reasonable definition regression (even with just one independent 
> variable) is a multivariate technique.  Therefore, it belongs in 
> .multivariate.

Well, I remain to the opinion that the multivariate package is not the 
place for univariate regressions. I think that we are looking here at a 
fundamental change in package names and so, which I think should be 
resolved BEFORE the first release, to ensure backward compatability with 
later releases.

>> Furthermore, the different types of variances remains unsolved, as
>>  they are variant's of each other and should be in one single
>> class.
>
> Unfortunately, this is inconsistent with the basic design of the 
> univariate statistics package. Having each statistic class compute
> just one statistic has lots of advantages -- one of which is that it
> is trivial to add alternative implementations for the same or similar
>  statistics without breaking compatability with existing code.

How would it break the compatability with the existing code?

>> And I differ in the basic idea of dealing with regression types
>> (LS, MRA MA).
> 
> Right now, we support only simple OLS regression. Post 1.0, we
> welcome ideas about how to represent and support alternative models.

The issue is similar to the variance types, not the lack of 
implementation in the current version. They are variants of the same 
univariate regression, so they need to be incorporated in that class.

Kim
-- 
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