commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Ward" <>
Subject Re: [math] SingularValueDecomposition
Date Tue, 18 Jul 2006 04:28:56 GMT
OK, thanks.

One wrinkle that I didn't anticipate is that the legal department at work
didn't give me the automatic yes that I expected. I did develop this in my
own time over a couple of weekends, and it's not in any way related to them,
but if legal is of the mentality that everything gets rejected
automatically, then their veto will prevent me from sending in the code.

As soon as I get the goahead from them, I'll follow the links you gave and
submit the code.



On 7/17/06, Phil Steitz <> wrote:
> 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
> <>
> 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]
> 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 for more
> general information about contributing to [math].
> On 7/17/06, Tyler Ward <> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message