On 11/25/13, 6:36 AM, Gilles wrote: > On Mon, 25 Nov 2013 08:46:46 -0500, Brian Wignall wrote: >> Hello, everyone. >> >> I am new and hoping to make my first contribution. I read through >> the Wish >> List, and I thought I could help quickly by starting with the >> special >> functions request. > > Thanks for your interest in Commons Math. > Contributions are very welcome, but contributors even more so.
+1 to that - welcome, Brian! > > By this, I mean that the most important thing is not to increase the > codebase, but to make it so that it is gracefully integrated in the > project. > > I did not read your patch in detail, but it is enough to already > detect > the drawbacks of automated translation from Fortran. > [We have an unfortunate example of this in the class > "BOBYQAOptimizer".] > > A few remarks (in no particular order): > * Existing functionality must be reused (e.g. "factorial"). > * Public instance variables are forbidden. > * Variable name must not contain underscores (unless it is a > global constant). > * Variables must be defined at the smallest possible scope and > must have > names as meaningful as possible (unlike customary in Fortran!). > * Commons Math's exception must be used exclusively. > * Global constants must be "final" (and their name must be in all > uppercase). > * Operators must be surrounded by space characters. > * ... > > IMO, a very important thing is to make the code as readable as > possible. > I know that you had to work already to obtain this result from the > output > of the translator, but some further improvements are needed so > that the > contribution looks like a Java source coded from scratch. +1 - we have been burned in the past by ports without enough focus on the underlying algorithms. A "faithful" port can be a good start; but what we always end up having to do is penetrate the underlying numerical algorithms and focus more on them than the sources being ported to get something that we can support. That can be interesting work and you can often get help from others in the community as you work through the issues. Have a look at [1] for some background on development guidelines for [math]. Running "mvn clean site" on a checkout containing your code will generate a checkstyle report that will call out the things Gilles mentions above (among others). Thanks again for your interest and contributions. Phil [1] http://commons.apache.org/proper/commons-math/developers.html > > Best regards, > Gilles > >> >> I created a JIRA >> (https://issues.apache.org/jira/browse/MATH-1066) that >> contains a patch for Bessel functions of the first kind. There >> are other >> Bessel functions that are relevant, but I figured I would post >> that, to get >> (minor, hopefully) suggestions or tweaks to get it ready, to >> streamline the >> process for other functions. >> >> The JIRA is a bit sparse, so some more details on the patch follow. >> >> Like several other open source packages, I started from Fortran >> code in >> Netlib; in this case, http://www.netlib.org/specfun/rjbesl . As a >> first >> pass, I enabled the double-precision lines with IEEE values >> already in the >> code and then put the Fortran code through f2j ( >> http://www.netlib.org/java/f2j/). This handled the >> straightforward parts, >> but it left in gotos and some other bits that needed cleaning. >> Getting the >> output of f2j to a decent place took more time and effort than I had >> anticipated, but it is passing the unit tests I put in (based on >> output >> from R, which uses a translation of the same Fortran code). >> >> I am looking forward to hearing thoughts and suggestions. >> >> Kind regards, >> Brian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
