# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

**Re: The Tables for Clearing the Lunar Distance**

**From:**Fred Hebard

**Date:**2003 May 22, 12:18 -0400

Bruce, Thank you so much for laying this out for us mere mortals. I am sure it was a lot of work to do so, and I very much appreciate the effort you have put forth to do this. Yours Truly, Fred Hebard On Thursday, May 22, 2003, at 11:57 US/Eastern, Bruce Stark wrote: > This is a belated continuation of the April 28th and May 5th postings > "Clearing a lunar" and "Converting a Lunar to GMT." It focuses on my > Tables. > > The first thing the Tables and work form do is square away the > details. If > altitudes were measured along with the distance, table 1 gives the > adjustment to > turn them into apparent altitudes of the centers. Or, if altitudes were > calculated rather than measured, the "W.W." tables "uncorrect" them to > turn them > into apparent altitudes of the centers. > > The W.W., (wrong way) tables were developed by working backward. Take, > for > example, the W.W. Parallax correction for the moon at 5? altitude and > 61' > horizontal parallax. Multiply the cosine of 5? by 61'. That gives the > moon's > parallax correction for a 5? apparent altitude. Taken to three decimal > places the > correction is 60.'768, additive. Apply that the wrong way. That is, > subtract it > from 5? to get 3? 59.'232. Then multiply the cosine of 3? 59.'232 by > 61' to get > 60.'852. Subtract that from 5? to get 3? 59.'148. Repeat another time. > There's no appreciable change from 60.852, so the W.W.P. correction, > rounded to the > nearest tenth, is 60.'9. > > Table 1 and the W.W. tables are ridiculously precise, considering how > forgiving lunars are of inaccurate apparent altitudes. But they don't > take up much > room, and might have other uses. > > The apparent altitudes of the centers, whether found with the help of > table 1 > or the W.W. tables, are usually designated by "m" and "s." But lower > case > letters don't always catch the eye. I decided to use the larger, more > noticeable, > "Ma" and "Sa" instead. Similar thinking affected the design of the > work sheet > and the other tables. Navigators aren't always wide awake and at their > brightest when working observations. They make fewer blunders if they > can quickly > find, and unambiguously recognize, what they are looking for. > > Since the true altitudes themselves are not used in the equation > there's no > reason to differentiate them, and (H~H) serves in place of (M~S). The > (cos M * > cos S)/(cos m * cos s) part of the equation was named "Q." > > Substituting the above symbols for the usual ones makes the equation > for > clearing (given in the May 5th posting) look like this: > > hav D = sqrt{hav[d - (Ma~Sa)] * hav[d + (Ma~Sa)]} * Q + hav(H~H) > > Tables 2 and 3 are refraction and parallax tables: table 2 for the > moon, > table 3 for the other body. Refraction is for 50? Fahrenheit and 30 > inches of > mercury. Values agree with those in the WW II era Bowditch, where they > are given > to the nearest tenth of a second of arc. For convenience the tables > also give, > next to the refraction and parallax corrections, each body's part of Q. > > To fit into tables 2 and 3 the (cos M * cos S)/(cos m * cos s) version > of Q > was rearranged to (cos M/cos m)(cos S/cos s). The first half answers > to the > same arguments as the moon's refraction and parallax, and the second > half to the > same arguments as the other body's refraction and parallax. To save > space, > everything before the first significant figure was dropped before the > values were > put in the tables. To prevent rounding error buildup a sixth decimal > place, > set off by a comma, was included. > > The part that goes in table 2 is negative. The part that goes in table > 3, > given directly, would be positive. But in absolute value it would > always be less > than anything in table 2. It never exceeded 12,7, as I recall. So I > applied > -12,7 (if that's what it was) to everything that went into table 3, > and +12,7 > to everything that went into table 2. That way the two parts can be > added to > get the total. A clever dodge, but an old one. > > Dr. Inman gets the credit for the particular arrangement of table 2. I > junked > my own design after examining table 34 in the 1894 print of Inman's > Nautical > Tables: "Corrections of the Moon's Altitude, and the Aux. Angle A." > > Table 3 starts out with a 2' interval for the altitude and picks up > speed > until the interval reaches 1?. Ordinarily this change of interval > would be a poor > feature. But it doesn't matter here because there's no interpolation. > Space > is saved, as are page turnings. > > Other than the sextant, and the observer's ability to use it, nothing > is more > critical to the accuracy of a lunar distance than the semidiameter of > the > moon. The sun's semidiameter is equally important when the distance is > from him. > The Almanac gives these values only to 0.'1 and in the case of the > moon, not > often enough. Fifteen years ago, for my own use, I penned manuscripts > of what > are now tables 4 and 5. These tables are based on the 1987 American > Ephemeris > and Nautical Almanac, the astronomers' version of the Almanac. It > gives values > to the nearest tenth of a second of arc. > > The physical diameters of moon and earth are constant, so the ratio of > the > moon's horizontal semidiameter to her horizontal parallax is constant. > From > Ephemeris data I took the ratio to be 0.2725. But that's for horizontal > semidiameter. When the moon's above the horizon she's closer, and > appears larger. > Directly overhead she's closer by the full radius of the earth. This > effect is > usually taken care of by a special "augmentation" table. To avoid the > need of a > separate table I concocted the formula: > > Augmented S.D. = (0.2725 H.P.)/(1 - sin H.P. * sin H) > > This is the basis of table 4. Entered with the approximate altitude > and the > nearest 0.'1 of H.P. from the Almanac, the table gives augmented > semidiameter > correct to the nearest 0.'03. Altitude is not at all critical for this > table, > so the apparent altitude can be used in place of H. > > Table 5, of the sun's semidiameter, will be two days off by the year > 2093, > according to my figures. At that time a revision might be worthwhile. > > Values in these and some of the other tables were taken to an extra > decimal > place so that, when added together, rounding errors don't build. It > would be > nonsense to interpolate between the values. > > Table 6 can be calculated well enough by taking the difference in > refraction > caused by a change of 16' in the altitude and multiplying it by the > square of > the cosine of the "Angle from the Vertical." > > The "K" table is made up of negative log haversines. I tried to > arrange it so > values could be quickly and easily found. "K" and "Q" are not > initials. They > are symbols, intended to be instantly picked out on the work sheet. > > A problem was presented by the + sign separating "hav(H~H)" from the > rest of > the equation for clearing. Not easy to get around without a cumbersome > table, > extra trouble in calculation, or loss of accuracy. After coming up > with the > "inside-out critical table" which gives every value in a (fairly) > reasonable > number of pages, I settled on the use of Gaussian addition logs. > Fortunately, > subtraction logs aren't needed. > > Unless you are curious about addition logs, skip the next paragraph. > > Suppose you have log A and log B, and need log (A+B). Subtract log B > from log > A. That gives you log (A/B). Enter the table with log (A/B) and it > gives you > log (A/B + 1). Add log (A/B + 1) to log B and you have log (A + B). > Since, in > my method, "log A" and "log B" are negative and the Gaussian positive, > its > absolute value is subtracted, rather than added. > > The "log Dec." table uses the same "inside-out" design as table 2. It > gives > negative log cosines for calculating comparing distances. > > Table 7 is based on ten times the number of minutes of arc in a > degree, that > is, 2400. Entered with 31.'8 it gives log (2400/318), which is 0.8778. > > Table 8 is based on the number of seconds in an hour. In the first > edition > this table presented the minutes across the top and the seconds down > the side. > This made the flow of change within the table slightly different from > that in > the K table and table 7. The difference led me astray one time too > many. I > substituted the present awkward-looking arrangement in the second > edition. Once > you're used to it, it works fine. > > Bruce > >