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: Graphs of Lunar Distances.
    From: Frank Reed
    Date: 2010 Oct 27, 21:15 -0700

    Denny wrote:
    "It has still not disinclined me from my final conclusion however, that one minute of arc (i.e. half a moa absolute from the 'truth') is about the best one can manage under normal circumstances..."

    This, of course, is EXACTLY what Feynman was talking about. This isn't his "conclusion" based on his data --it's the pre-conceived notion that he took into this process.

    And wrote:
    "And yes, I have discovered there was another bug in what I was doing, but it was not not the programming of the calculator. That is correct."

    And there are no doubt more. This is one of the problems that crops up now and then when modern celestial enthusiasts attempt lunars. They frequently attempt to "roll their own" solutions when their are excellent, easy methods available from the historical period, as in Bowditch and Norie, and also excellent modern solutions like Bruce Stark's tables or like my software tools (which have been well tested by many users so I feel comfortable calling them "excellent" despite the way it sounds). And having "rolled their own" creative solutions, they get results which are mediocre and then blame the method itself.

    And wrote:
    "For Lunar Distances, an average of at least six measurements is needed and is going to improve accuracy considerably, and this is what was actually done of course"

    Historically, in the logbooks I've examined, it was normal to average anywhere from three to ten but most commonly four. This works with lunars and not as much with modern line of position altitude sights because there is no horizon involved. The number of sights improved the accuracy of the results with lunars in proportion to the square root of the number of sights, so we get a lot of benefit from the first few additional observations but decreasing impact with larger numbers. We can (nearly) double the accuracy of a lunar observation by averaging four sights, but to double it again requires 12 more sights (16 total), and at that point we may well bump up against the systematic error in the instrument itself which probably makes those additional sights wasted effort.

    And wrote:
    "with two other navigators taking sights simultaneously for altitudes wherever possible."

    It was by no means necessary to have two assistants, though if they were available, definitely convenient. It was quite common to measure the altitudes of the Moon and the other body before, shoot a few lunars, and then measure the altitudes again after. The before/after altitudes would be average to bring them in line with the time of the averaged lunars. There were many options, but a nice choice would be to measure the Moon's altitude, shoot two lunars, measure the Sun's altitude, shoot two lunars, and then measure the Moon's altitude again. Then the Moon's altitude is found by averaging, the lunars are averaged, but the Sun's altitude is used as is and even provides an accurate time sight for the local time. The Sun's altitude was more important for accuracy than the Moon's.

    And wrote:
    "Nevertheless all that ignores the serious problem of taking the Lunar distance and altitude sights at sea in a seaway, with the restriction of limited time to take them in twilight only if altitudes are simultaneously taken. No doubt this is why altitudes would have been calculated more often - so lunar distance sights can be take in darkness when it is more convenient for stars."

    That's a theory, but it's a theory that does not match the evidence of history. In fact, altitudes were rarely calculated by navigators at sea. They were observed --because it was easy, accurate, and saved a lot of paperwork. Something on the order of 80% of lunars (at sea!) were taken in daylight, and so getting altitudes was rarely a problem. When lunars were taken at night, the altitudes were observed, too. The Moon's presence in the sky makes this much easier than modern navigators expect. The altitudes are less accurate when measured at night, but that's generally not a problem since the lunar clearing process is not especially sensitive to the accuracy of the altitudes, especially when the objects are high in the sky, and especially, for the Moon's altitude, when the measured distance is close to 90 degrees. In addition, a common error in both altitudes, which might arise from an indistinct horizon, is even less of a problem.

    Of his last Moon-Jupiter lunar, he wrote:
    "equiv to 3/4 of a minute of arc. One of my better ones! I must be getting better at it."

    Nope. In fact the error in that lunar was 0.4' in the observed distance. But to repeat, 64% of his previously posted Moon-Jupiter lunars were within +/-0.22'. So what is responsible for the discrepancy in the calculations? Right away, there's one mistake: no augmentation of the Moon's semi-diameter. That explains 0.2'.

    -FER


    ----------------------------------------------------------------
    NavList message boards and member settings: www.fer3.com/NavList
    Members may optionally receive posts by email.
    To cancel email delivery, send a message to NoMail[at]fer3.com
    ----------------------------------------------------------------

       
    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