commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [math] SingularValueDecomposition
Date Tue, 18 Jul 2006 02:22:28 GMT
Hi Tyler,

Thanks for your interest in contributing to Commons Math.   In general
(though see disclaimers below), taking "textbook algorithms" and
implementing them with original code is fine, though often textbook
algorithms don't really work too well in practical applications, and
[math] is really an applied math package (maybe part of why we don't
add the "s" - he he).  It is also usually fine to implement advanced
algorithms found in scholarly journals or specialized texts.  What is
*not fine* is
a) copying source code (from any source) without getting the original
author(s) to agree to grant license to the code to the ASF (we have a
process for this, which Luc is going through now with his Mantissa
contribution, referred to below)
b) "translating" source code without satisfying requirements in a)
c) implementing algorithms that have been published with restrictions
or on which there are known patents.
d) any original contribution that you cannot make or are unwilling to
make under the terms of the Apache Contributors License Agreement
<http://www.apache.org/licenses/icla.txt>

While some people think that math algorithms cannot be patented, there
are others, including some of those who publish them, who feel
otherwise.  See, for example

[NR] http://www.numerical-recipes.com/infotop.html#distinfo

This is why we require b) above and c).  Whenever we have even thought
about implementing an algorithm presented in [NR], we have made sure
to find an additional source in the academic literature describing the
algorithm that does not attribute it to [NR] as their invention.  That
is so, even if we do not look at the code in [NR] in building our
clean room implementation, if our code ends up "looking like" a
translation of theirs, we can claim that we are just implementing a
widely used, standard algorithm.  This is one of the reasons that we
favor widely used, standard algorithms.  The others are
maintainability / approachability, consistency with other packages /
systems that our users may want to have interoperability with, and
verifiability (availability of test data or ability to validate
against other packages).

See http://jakarta.apache.org/commons/math/developers.html for more
general information about contributing to [math].

On 7/17/06, Tyler Ward <ward.tyler@gmail.com> wrote:
> This is why the householder transformation was so simple. There are better
> ones, but I thought I'd play it safe and implement it directly from the
> textbook definition to not run afoul of any copyrights. All of the code came
> from the text of textbooks, I didn't take any code from anywhere.
>
> How should I send this code in, should I just attach the files to this email
> thread?
>
The link I referenced above explains how to submit patches with JIRA
tickets.  Don't hesitate to ask if you have problems getting set up
with subversion (our source management system) and JIRA (the issue
tracker).

The best first step for SVD is to take a look at the class Luc
mentioned that implements QR decomposition and see how you might be
able to leverage / build on the Householder transformation implemented
there.  The class I am referring to is
org.apache.commons.math.linear.QRDecomposition.

Thanks in advance for your contributions to commons math!

Phil

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