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. Thanks, Tyler On 7/17/06, Phil Steitz <[EMAIL PROTECTED]> 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 <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]
