good chemistry is complicated,
and a little bit messy -LW
Old NumberCrunching Modulesby Anonymous Monk
|on Aug 13, 2012 at 00:04 UTC||Need Help??|
Anonymous Monk has asked for the
wisdom of the Perl Monks concerning the following question:
I was thinking about asking yesterday, and ran across this "elitist" posting which bothered me.
I don't have anything in CPAN (yet), but I've been writing perl since the early 1980's. I even did a partial port of perl to QNX-2.x which I never passed on (it was just commenting out all the networking). Twenty five lines to a function, I've had many functions run to 10 or more pages. I'll chalk that up to engineering versus computer science, but others may disagree. And it has little to do with the topic anyway.
Math::Brent has been around a long time (1995 or so), and it apparently works just like Brent's method for minimization does in every other implementation. The code looks like a perl version of FORTRAN-II, but so does Numerical Recipes (pick your language, they all look like FORTRAN_II to me). And seeing as I grew up with FORTRAN_IV, looking at FORTRAN_II (in Perl, C, Pascal or whatever) isn't a problem.
There have to be lots of potential Perl modules implementing old FORTRAN code, and the biggest problem with most of these is getting the documentation correct. The code (if implemented properly) just works.
I run Debian Linux, and there is the concept of a non-maintainer upload. There has been a bug filed against Math::Brent for 4 years, which is correct. There is a documentation error in Math::Brent, and to fix it requires the deletion of 4 characters in the POD. Does some similar mechanism exist in CPAN?
I am working on a module (or set) to analyze what is nominally Map data produced by GPS, but could be things like surface chemistry as a function of position.
Part of what I need to do is Cross Validation, and I don't see how I can make use of Math::Brent in its non-OO form. Consequently I am re-implementing Math::Brent in an object oriented form. Having read about non-derivative optimization of 1D functions a bit, I am thinking about a modification (thanks to Crenshaw).
Sorry, too long.
Whenever I get this Map thing working, I could easily make an update to Math::Brent to fix the documentation, which would get rid of a 4 year old bug. Is there some accepted practice about re-implementing functional code as OO? Math::Brent::OO? If I make a change to how Brent works, what should a person do? Option to Math::Brent::OO->new(), or a new module?
The idea of changing Brent, a person needs to test. There are many modules in Test::, I don't see any involved with verifying how floating point code works on different architectures. I have a bunch of test functions and results assembled. Suggestions?