NavList:

   

Reply

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.

=========================

Then-
"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
thread...".

So?

" ...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
converge?

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.

George.

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.

   

Reply