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: A simple three-body fix puzzle
    From: George Huxtable
    Date: 2010 Dec 10, 11:32 -0000

    It's remarkable, the lengths Frank Reed will go to to avoid admitting that
    he has got something wrong.
    Frank provided a link to the back pages of the Nautical Almanac, with a
    scan of an extract, adding-
    "Note that in the last line, L and B with subscripts refer to longitude and
    latitude, but all we need here is the difference in these in miles which is
    given by (AE-BD)/G and (CD-BE)/G".
    I pointed out that these differences would need multiplying by 60 to put
    them into miles, and Frank countered-
    "Yes. IN MILES. If the intercepts are in miles, then (AE-BD)/G and
    (CD-BE)/G are in MILES (A,B,C, and G are all dimensionless --just numbers--
    while E and D have the same units as the intercepts)."
    Throughout those pages in the Almanac, the intercepts p were defined as
    being in degrees, NOT IN MILES, as in
    p = Ho - Hc
    where the angles Ho and Hc are in decimal degrees
    Indeed, on page 282, for plotting on a chart, are the words  "convert p to
    nautical miles by multiplying by 60" .
    And in the line immediately obove the one he was trying to "explain", the
    example given provided values of
    D = -0.6714,  E = 0.1278
    These values were calculated on the basis of the intercepts being given in
    degrees, not in miles.
    Frank is perfectly entitled to define his intercepts differently if he
    wishes, but when he is referring to a particular explanation in the
    Almanac, he will only confuse his readers if he does so WITHOUT SAYING SO.
    Frank continued-
    "Now, there may be some navigators somewhere on the face of the Earth who
    normally give their intercepts in degrees, but I have not met one."
    The Nautical Almanac, on those quoted pages, is one that does.
    He continued
     "To you navigators out there who DO quote intercepts in degrees, I am
    confident that you can make that oh-so-terribly-difficult unit conversion
    on your own. For everyone else, my previous statement was correct."
    Very scathing, Frank. No problem about multiplying by 60, or dividing by
    60, as long as SOME CLUE is provided that a different procedure is being
    adopted than that given in the pages that were being referred to.
    "George, you went on at some length about the "iterative" aspect of these
    equations, apparently imagining that this is a fundamental property of them
    Yes. That's because it IS a fundamental property of them. Such iteration
    may not be necessary on a flat Earth. But we are not dealing with a flat
    Earth. Frank omitted to mention that his calculated offsets from the
    estimated position might need reiteration if they were too far away.
    ", and then you described using them to find a two-body fix, possibly in
    another hemisphere. This is like using a wrench to hammer a nail. These
    equations are intended to replace the plotting step on a large-scale chart
    that we're all familiar with: drawing LOPs at their respective azimuths
    based on their intercepts from a point near our estimated position and then
    finding the point where they all cross (as nearly as possible), but the
    equations do so in a statistically sound way in a least squares sense. And
    EXACTLY like the plotting step, these equations are based on a simplifying
    geometric assumption of a flat Earth and straight LOPs. The idea that these
    equations have to be iterated when the new position is more than a dozen or
    two dozen miles from the assumed position is no more remarkable than saying
    that one should re-work a standard LOP plot under similar circumstances.
    And in fact, if you're using this system of analysis properly, you would
    almost never find yourself in a position where you need to iterate. Sure,
    you can coax these equations into the more academic task of finding a fix
    when the original position is completely unknown, which does require
    multiple steps of iteration, but that's not what they're for. ...Get a
    hammer when you need to hammer a nail.
    Leaving aside the hammer / nails stuff, I'm not sure what Frank is arguing
    about here.  There is nothing remarkable about the need to reiterate in
    certain circumstances: did I claim that there was? It all depends how close
    your estimated position is to the true position. Frank says "a dozen or two
    dozen miles". The Almanac suggests reiteration, if applying the procedure
    shifts the position by more than 20 miles. We all seem to agree.
    But what is the basis of Frank's statement, then, that "if you're using
    this system of analysis properly, you would almost never find yourself in a
    position where you need to iterate."? Is he saying that every navigator,
    using celestial observations, always knows beforehand his position within
    (say) 20 miles?
    And Frank's parting shot? "Finally, none of this business about iteration
    has any bearing whatsoever on the topic being discussed previously in this
    " ...nor does it invalidate or even modify in any useful way anything that
    I wrote previously.".
    Frank presented his "result" as if it was the final answer, but under some
    circumstances, it isn't. I pointed that out.
    It happens to interest me, the way this procedure behaves when given an
    estimated position as a starting-point that is a long way from the true
    position. That may not be of interest to Frank, but that's no reason why it
    should not be discussed on the list; as it may (or may not) be of interest
    to others. Implemented on a computer, multiple reiterations require nothing
    but a few milliseconds. Is there, then, any need to provide an estimated
    position as a  starting-point at all? If, in every case, we simply let the
    algorithm loose from a fixed starting-point, such as the North Pole, to see
    where it ended up after as many iterations as it thought fit, would it
    always converge at the correct spot in the end, or would it find itself
    wandering up some blind-alley, or get itself hopelessly lost?
    And one situation in which it might well  provide the wrong answer is when
    only two bodies have been observed, in which case there are two valid
    results, the intersections of the two position circles. Starting from the
    North Pole would flush out one, which may or may not be the one that's
    wanted. Presumably, starting from the South Pole would produce the other.
    There are, I''m aware, more elegant geometrical procedures for calculating
    the intersections of two circles than this iterative procedure.
    Following on from that, taking a 3-point observation, starting from (say)
    the North Pole each time, is there any combination of position lines which
    will fool this algorithm into providing a silly answer, or a failure to
    In my case, the algorithm is implemented on a programmable pocket
    calculator, which is inconvenient for searching out a lot of phase-space.
    But to the extent I've been able to test it, the algorithm seems to be
    remarkably well-behaved and robust.
    contact George Huxtable, at george{at}hux.me.uk
    or at +44 1865 820222 (from UK, 01865 820222)
    or 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