Welcome to the NavList Message Boards.

NavList:

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

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    or...
       
    Reply
    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
    >
    >
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Join NavList

    Name:
    (please, no nicknames or handles)
    Email:
    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:

    Email Settings

    Posting Code:

    Custom Index

    Subject:
    Author:
    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