commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject RE: [MATH] Contributing
Date Tue, 10 Aug 2004 21:38:13 GMT
Kim,
 
Sorry for the response latency.  Thanks in advance for any contributions that you can make
to [math]. One thing to keep in mind is that we are trying to focus on commonly used stuff.
 So, e.g. a basic GLM package would be more interesting than RMA.   Of course, if all is available....
 It would be great to start by making the needed improvements / extensions to the current
RealMatrix implementation to support a numerically sound multivariate regression / ANOVA package.
 I would be less concerned about fitting the current architecture than laying the groundwork
for good extensions.  We need to maintain backward compatability, but we can certainly extend
as necessary.
 
Another thing to keep in mind is that we need to make sure that we avoid any potential IP
issues.  That means that you need to be able to agree to the terms of the Apache Contributor's
License Agreement <http://www.apache.org/licenses/#clas> and you need to avoid "encumbered"
code / algorithms -- i.e. code that comes directly or via translation from sources protected
by restrictive copyrights or patents (e.g. translation to Java from "Numerical Recipes" C
code).   If your code actually belongs to you (i.e. your employer does not own it or will
allow you to contribute it) and is your implementation of standard algorithms, there should
be no problem.
 
Thanks again for your interest and feedback.
 
Phil
 
 
-----Original Message----- 
From: Kim van der Linde [mailto:kim@kimvdlinde.com] 
Sent: Tue 8/10/2004 6:02 AM 
To: Jakarta Commons Developers List 
Cc: 
Subject: Re: [MATH] Contributing



	Hi Mark,
	
	Logically, the modules have to fit in with the existing structure. I was
	anyway already planning to revise the MVE module and start to
	incorporate the commons-MATH package. I wil have a look at the extisting
	package and come back with classes that would fit in, or post the
	questions here when I can not figure it out.
	
	Cheers,
	
	Kim
	
	Mark R. Diggory wrote:
	
	> Hi Kim,
	>
	> I think we have a bit of work to complete in extending the api into
	> areas of multivariate analysis/statistics and would be interested in
	> implementations in that area. I think the big thing is that we would
	> like to see implementation be based on the existing library architecture
	> as well, so goal might be to see if these could be easily modified to
	> work with the existing Matrix/Statistics classes in our api.
	>
	> thanks,
	> Mark
	>
	> Kim van der Linde wrote:
	>
	>> Hi Phil,
	>>
	>> Thanks for the answer, and I was talking about numerical stability.
	>>
	>> On an other track, if the math group is interested, I can provide some
	>> classes for Multivariate Minimum Volume Ellipsoid outlier detection,
	>> Covariances, common matrix types as SSCP, covariance and correlation,
	>> multivariate euclidian and mahalanobis distances and maybe some other
	>> classes as model 2 regressions (RMA: Reduced Major Axis). Interested?
	>>
	>> Kim
	>>
	>> Phil Steitz wrote:
	>>
	>>> Kim van der Linde wrote:
	>>>
	>>>> Hi All,
	>>>>
	>>>> I have a question. How stable are the matrix classes as implemented?
	>>>>
	>>>> Cheers,
	>>>>
	>>>> Kim
	>>>>
	>>>>
	>>> Hi Kim,
	>>>
	>>> If your question is about the API, then the answer is that we are
	>>> planning no changes prior to the imminent 1.0 release.  If your
	>>> question is about numerical stability, performance or correctness
	>>> there are two things to say:
	>>>
	>>> 1) The javadoc describes the algorithms used to perform matrix
	>>> operations.  The algorithms are general purpose, so they will not
	>>> always give the best results (or performance) for all matrices. For
	>>> most practical problems, the implementations should work fine. Have a
	>>> look at the docs and consult a numerical linear algebra text (or a
	>>> numerical analyst) or ask more specific questions here if you want to
	>>> know about individual operations. Eventually, we will provide support
	>>> for a wider variety of algorithms.  For 1.0, what you see now is what
	>>> you get.
	>>>
	>>> 2) Our confidence in implementation correctness is based pretty much
	>>> entirely on the unit tests at this point. This is new code, not yet
	>>> released. We are in the process of cutting a release candidate
	>>> including these classes. User feedback and/or additional test cases
	>>> will be greatly appreciated.
	>>>
	>>> Phil
	>>>
	>>> ---------------------------------------------------------------------
	>>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
	>>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
	>>>
	>>
	>
	
	--
	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
	
	

Mime
View raw message