|
 |
I sent this in about a month ago, and haven't heard back. This doesn't mean it
will never be published, but I thought I'd post it here anyway.
Re: DCB results
Sometimes a representative line shows up, not in the code itself, but in an
email about the code.
[See attachment, properly printed and photographed en una mesa de madera.
Alt Text: "Replace the dotprod and sum with a Do loop. That will not have a
problem."]
Because, you know, reverting to forty-year-old coding style is an effective
debugging technique. And never mind that the bug has already been fixed, and the
corrected version posted, with a copy sent to the researcher who found the bug
as indicated by the little paper-clip symbol for the Cc'd message sent at noon.
Instead, I ignored this sage advice from my advisor, tracked down the source of
the discrepancy by applying the radical and rarely-used RTFM method, and then
proved, not only that my code is correct, but that the novel method it applies
is mathematically equivalent and numerically superior to an existing method.
----
The Full Story
Research code is often the ultimate in one-off code, its main purpose being to
demonstrate some novel application just well enough to spit out enough numbers
to make a pretty graph suitable for publication in some obscure journal. The
research code being discussed here is not that kind of code. This software is
meant to be used by actual engineers to help figure out, for example, if some
important part of an airplane is likely to break sooner, or later.
The line of Fortran 95 in question is this.
zpi = 0.5d0 * DOT_PRODUCT( zU,MATMUL(zAMATRX,zU) )
The odd thing is that this energy calculation works fine in my code, but the
following line does not produce the correct result.
zpi = 0.5d0 * SUM( zU*MATMUL(zAMATRX,zU) )
A mathematically-minded reader may notice that this looks like it simply
replaces Fortran's intrinsic dot product function with the very definition of
the dot product. To confuse matters further, in a colleague's code based on
mine, the latter is the form that worked correctly while the former did not. The
only reason the second form was in my code at all was to verify this disparate
behavior, and I had not yet reverted it after doing so. An actual Fortran
programmer might clue in to the odd naming convention used and speculate that
there are some funky complex-number shenanigans going on here.
This hypothetical actual Fortran programmer would be correct. By first RTFM,
then applying carbon and clay to the reverse of a scrap of paper fished from the
recycling bin, and finally verifying the math using a computer algebra system, I
proved that Fortran's dot_product is the correct function to use in this case.
This is contrary to the guidelines published by other researchers in this field,
a finding to be included in the next paper I hope to write for publication in
some obscure journal.
OK, so it's not P vs. NP, but it sure beats being a junior webmonkey for
iMySuperMegaEconoStoreOnline.com.
----
"The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny...'"--Isaac Asimov
Post a reply to this message
Attachments:
Download 'p1010062.jpg' (415 KB)
Preview of image 'p1010062.jpg'
|
|
