![Welcome to the NavList Message Boards.](../sx1.jpg)
NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
From: Frank Reed
Date: 2016 Feb 26, 13:37 -0800
Paul Hirose, you wrote:
"He [Plauger] says you should never attempt to "help" a trig function by removing multiples of a full circle from the argument. If the function was written by a proficient numerical analyst, it already does that, and probably better than you!"
It's an interesting, and I must say very smart point, but I must also say that its specific significance has faded away as the decades have passed. There's no real harm in the creation of a circle-range "helper" function like this, and it may well aid in debugging. I can instantly recognize 270° as a multiple of 90 when I see it as an intermediate value in a calculation, but even a case close to the standard range, like 1170°, does not jump out as 360·3+90°. The downside for using such a function when you don't have to is absolutely trivial in modern computing. Most of the detail-driven "point optimizations" that we all worried about 25 years ago when Plauger was writing became irrelevant around the year 2000.
In any case, I don't think we need to re-write or optimize Henning Umland's code. It works fine with a tiny change. All that's required is to rename the function trunc(). Previously I did this with a longer, unique name but upper-casing just one letter fixes it, too: do a global replace of trunc( by Trunc( and that resolves the problem.
By the way, our efforts to reach Henning Umland have paid off. He emailed me this morning, and he says he will fix the code when he has time to do so. Normally I don't help people fix their code on the Internet without being asked. This is a special case for several reasons. Even though this is not how I personally do almanac calculations in most cases (not since about 2003), this is a nice library of code, and it's convenient to have it available without having to think about different versions and forks and modifications and all that. Also, Umland's web site has a unique status that is shared by one of my web sites: it's old. It's so old that it pre-dates Google. And that places it in a special garden of relics that are given special treatment by Google's search algorithms. As long as it exists, Henning Umland's celestial navigation site will get high ranking in Google searches (and other searches since everyone follows Google's lead). Most of you have seen another example of this when you have searched for celestial navigation. Within the top two or three hits for this general topic, you will find a quite mediocre site celestialnavigation.net. Among all the possible resources for celestial navigation on the Internet, this site by measure of its content, ought to rank somewhere around 1000 to 2000 or lower. It's near the top because it's old. Like Umland's celnav.de and my clockwk.com, it's a dinosaur from the pre-Googlonian epoch. Since Henning Umland's site will always rank high in Internet searches, it's worth making sure that his code continues to work so that those searching for useful celestial navigation code can find it without being discouraged or, worse yet, spreading copies of broken code.
Frank Reed
Clockwork Mapping / ReedNavigation.com
PS: This issue of high-ranking of old domain names, including my clockwk.com, is one of the things that persuaded me to bring back my old business identity, slightly modified. You'll see "Clockwork Mapping" more frequently from now on in my signature and in the technical contact details at the footer of some NavList pages, too. That's just me. :)