# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

**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 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---.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. ================================================================