Thank you both, Gilles and Phil, for the warm welcome and for the detailed
suggestions.

It will take a little longer than I had anticipated to get this code up to
standard, but I will keep at it. Nothing ahead looks too onerous;
hopefully, soon it will be ready.

Thank you again for your time and guidance.

Regards,
Brian

On Mon, Nov 25, 2013 at 11:53 AM, Phil Steitz <[email protected]> wrote:

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

Reply via email to