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: Lunars with SNO-T
    From: George Huxtable
    Date: 2004 Oct 28, 11:03 +0100

    I recently sent a message about Alex Eremenko's lunar distances, which
    appears to have got blocked in its way into the Nav-l server.
    Since then, I have had second-thoughts about the last part of that message,
    so am posting this message as an addition. With luck the two will arrive
    together as the log-jam clears.
    Here's the relevant part of that message, once again.
    Finally, I asked Alex this question about his second set of lunars-.
    >> One minor puzzle arises, however.
    >> If I sum the 5 values of ERDIST, and
    >> divide by 5, the average comes out at -0.02, not -0.1.
    >> And, more strangely,
    >> if I sum the 5 values of ERLONG, and divide by 5,
    >> I get an average of +1.6
    >> minutes, not -2.1 as stated.
    >> Not that it matters; all these values are well
    >> within the error range expected from a lunar.
    >> But what causes a simple
    >> averaging to go wrong?
    Alex replied-
    >I also noticed this. I think this is a question to Frank Reed:
    >how his program really works. I introduced the row data and
    >printed what his program returned. Then I introduced the average
    >of my row data and printed the program output.
    >So I am only responsible for computing the
    >averages of GMT and DIST,
    >which I computed by hand (and then verified with my calculator:-)
    I credit Alex, as a mathematician, with the ability to correctly average
    his raw data of GMT and DIST, even for sexagesimal quantities. But it would
    be interesting to know exactly what were those averaged values that were
    fed back into Frank Reed's program, and whether any rounding had taken
    That discrepancy in calculated longitude, between -2.1' for the longitude
    of averaged distance/time, and +1.6' for the average of longitudes, is
    well, well within the expected precision of any lunar. So there's no
    discredit to Frank's program. But it's interesting nevertheless, and I
    can't break the habit of a lifetime, in wishing to ask further questions
    about it. After all, discrepancies are far more interesting than
    Such a result might well indicate that we are approaching, but not yet
    reaching, the limits of the simple averaging procedure, as we have
    discussed in such detail recently on this list. That procedure relies on
    quantitities changing linearly, showing a straight line when plotted
    against time. Or nearly so, anyway; with significant curvature causing the
    assumptions to break down.
    Alex's second set of lunars lasted over a period of 18 minutes or so, and
    in that time the apparent lunar distance changed by about 6', in a lunar
    distance of over 70d. Without doing calculations, it seems hard to credit
    that there can be any significant non-linearity in the true lunar distance
    over that small range, though we know it can become important when the
    distance gets really small.
    What about curvature in the corrections, however; particularly in the Moon
    parallax correction, which in some circumstances can be as much as 1
    degree?  We know that it varies by cos (altitude), which is itself
    non-linear. And under some circumstances the Moon's altitude can change by
    15d in an hour, though it must have been less than that in that Florida
    observation. I would put my money on changes in the slope of the Moon
    parallax correction, over the 18 minutes of the observation, giving rise to
    the small discrepancies that we see. But in practical terms, such small
    discrepancies are negligible when weighed against the inherent inaccuracy
    of a lunar, so there's nothing that needs "fixing".
    Frank may have a simpler explanation.
    That was what I sent yesterday.
    Since then, I have pondered a bit more about it. Can the small difference
    between the avarage-of-longitudes, and the longitude of averaged lunar
    distance / time, be related to rounding errors in the process of averaging
    and then entering that average into Frank Reed's on-line lunar calculator?
    In that calculator, times can be entered to the nearest second, which is
    more than adequate for any lunar. Lunar distance can be entered to the
    nearest 0.1 arcminutes, which is also quite adequate for most purposes, but
    may shows up in a nit-picking enquiry such as this one.
    If lunar distances are quantised to the nearest 0.1', then there must be a
    possible quantisation error of ?.05 arc minutes, which could give rise to a
    discrepancy in the resulting longitude of ?1.5 arc-minutes, or thereabouts.
    This is far better accuracy than anyone could expect from a lunar, but it's
    the same order (if somewhat less than) the small discrepancy we are trying
    to explain.
    My own averaging of Alex's second lunar set gives mean GMT of 0:26:29.4,
    and DIST 70d 41.02', but my sexagesimal arithmetic is notoriously
    unreliable. Alex was forced to quantise this to the nearest second and the
    nearest 0.1 arc-minute. Quantised to the nearest 0.1' this would be entered
    as 70d 41.0', which is damn near the same thing (going against my argument
    that such quantisation might have caused the discrepancy). It depends on
    what Alex entered for his averages.
    The point arises, that where very-accurate observers measure lunars from on
    land and average a long string of distances, this may be sufficiently
    precise to allow another decimal place in the lunar-distance data-entry
    routine. Just a suggestion. Otherwise, it suggests that a more-accurate
    average longitude will be obtained by clearing each observation
    individually, then averaging the many resulting longitudes, rather than by
    clearing the averaged lunar distance. This is practicable only because
    clearing lunar distances, using Frank's program or a similar technique, has
    become so quick-and-easy.
    However, such errors are negligible compared with the scatter that will
    occur in most lunar observations.
    contact George Huxtable by email at george---.u-net.com, by phone at
    01865 820222 (from outside UK, +44 1865 820222), or by mail at 1 Sandy
    Lane, Southmoor, Abingdon, Oxon OX13 5HX, UK.

    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