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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
