Welcome to the NavList Message Boards.


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

Compose Your Message

Add Images & Files
    Re: The Tables for Clearing the Lunar Distance
    From: Fred Hebard
    Date: 2003 May 22, 12:18 -0400

    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

    Browse Files

    Drop Files


    What is NavList?

    Join NavList

    (please, no nicknames or handles)
    Do you want to receive all group messages by email?
    Yes No

    You can also join by posting. Your first on-topic post automatically makes you a member.

    Posting Code

    Enter the email address associated with your NavList messages. Your posting code will be emailed to you immediately.

    Email Settings

    Posting Code:

    Custom Index

    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site