All the Perl that's Practical to Extract and Report

Perl Advent Calendar 2006-12-16

tsee on 2006-12-17T11:26:30

I just read today's "Perl Advent Calendar" (http://perladvent.pm.org/2006/16) entry and found out that in today's entry, Jerrad Pierce introduces one of my modules, Number::WithError (). Yay!

Now, he certainly has interesting things to say, but to cut down on the dependencies, he suggests commenting out three lines of the module code. Sure, I mean, it's Free Software. You could do that and even release the same module with just this change under a different name! But he goes on to say:

If you'd rather avoid installing the first three, you can do so by commenting out the following lines in v0.06 of Number::WithError with no apparent side-effects

"With no apparent side-effects"?
The test suite is failing all over the place because you have just removed the implementation of the tangent function!

Now, to be fair, he has a point. The dependencies are, at this stage, just there for tangent, which would otherwise be

sub my_tan { sin($_[0]) / cos($_[0]) }
# or rather in the module's context
sub my_tan { CORE::sin($_[0]) / CORE::cos($_[0]) }

Originally, I intended to leverage the implementation of the various less-common trigonometric and hyperbolic functions found in Math::Symbolic and add them to the repertoire of Number::WithError. I haven't done so because I didn't need it at the time. Then I forgot about it. Doh.

If it was just for the implementation of those ten or so functions, it would be questionable whether the dependencies (which are all pure-Perl, at least) are worse than duplicating a couple of functions. But there's more: Gaussian error propagation involves derivatives. Other than that, it's a straightforward formula. Math::Symbolic can compute derivatives for you. Got the idea?

Basically, one would get the implementation of most code in Number::WithError for free by generating the derivatives of the functions using Math::Symbolic and compiling them to Perl subroutines using Math::SymbolicX::Inline during the package BEGIN time. This made particular sense since hand-coding every routine was rather prone to small errors and unless he does the math by hand, it's not necessarily obvious to a programmer reading the code why it does what it does.

Fact is, I didn't do it back then. I don't even remember why. Probably some time constraint or "let's get this working before I make it elegant" thinking. It doesn't matter. I don't think publicly suggesting users to comment out random code is a good idea. I'll forward the bug reports stemming from this if they surface. ;)

Steffen

Ummm

belg4mit on 2006-12-17T16:19:52

Well, the test suite wasn't especially helpful given the dependencies (in particular Module::Build failed three or four different ways on two different platforms for me). Believe it or not, I did in fact try various things after "commenting out random code" (it's a little too specific to actually be random). And although I cannot duplicate the results now, I seem to recall tan() somehow magicaly working work just fine last night. In any event, yes, tan() is just sin()/cos() and anyone using this module ought to know that already; esp. if they're anglophones and the SoaCahToa bit doesn't jog their memory. So, I feel you're probably being just a tad hypersensitive here. I will of course, change the "comment out these 3 superflous lines to" "patch them with this slightly less superfluous line." As for forwarding bug reports, it might be more productive to tidy up the code? Either "more elegant" or "fewer extraneous dependencies."

Patched:

belg4mit on 2006-12-17T16:47:24

Entry ammended.

Re:Ummm

belg4mit on 2006-12-17T17:12:05

I also happen to get many failed tests regardless of the inclusion of tan (32 with, 33 without), so "The test suite is failing all over the place because you have just removed the implementation of the tangent function!", is a bit of an exaggeration. See RT.

Re:Ummm

tsee on 2006-12-18T12:33:20

I have a couple of things to note. I'm a hurry, so please forgive me if I jot them down in a list:

- Please try Number::WithError 0.08 which is on its way to CPAN now. It fixes the bug that would make the constructor tests fail if Math::Symbolic wasn't loaded. Why the tests didn't fail if M::S was loaded is completely opaque to me, but the problem was related to (non) stringification of Math::BigFloat objects.

- That release also removes any dependency on Math::Symbolic*.

- How is this related to Module::Build? If that fails for you, a good two-digit percentage of CPAN won't work on your system.

- I understand that you did run various tests before suggesting the code to be commented out. Since the tests failed for me as soon as I did that, I assumed you didn't. Funny that it would work for you, but then again, the bug that led to release 0.08 took me all morning to track down, so it's not really that funny in retrospective...

- SoaCahToa is a term I haven't heard before. I had to look it up. But I'm not anglophone either.

- The comment about fowarding bug reports was just a pun. :)

Anyhow, the issues should be gone in 0.08. Thanks again for writing about one of my modules. I appreciate it - regardless of what my journal entry might read like.

Steffen

Re:Ummm

belg4mit on 2006-12-18T12:47:11

* Re: try Will do

* Re: M::B it doesn't always fail, and not in those ways. How does it relate? All of the build and test errors desensitized me to those that followed. Besides, how seriously do most people take test failures? It's usually a judgement call (80%+ success seems pretty good) since they all have the same weight (that might be an interesting extension... bumps and bruises vs. core meltdown)

* Re: SOACAHTOA Yes, it's a mnemonic for learning gemoetric relationships of a triangle's sides and angles.

* Re: pun/read Yes, probably. Sorry. No worries. I've been edgy as publishing day after day is rather stressful, on top of which I have grad school applications and everything else.