NavList:

   

Reply

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
place.

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
agreements.

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.

George.



================================================================
contact George Huxtable by email at george@huxtable.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.
================================================================

   

Reply