NavList:

Ref http://www.fer3.com/arc/m2.aspx?i=115090

[NavList] Re: Rejecting outliers: was: Kurtosis.
From: geoffreykolbe---com
Date: 01 Jan 2011 09:41

HAPPY NEW YEAR TO ALL !!!

To the special Attention of both Peter Fogg, and Geoffrey Kolbe,

Dear Peter and Geoffrey,

Geoffrey, you have very smartly expressed in a few words a "rule of behavior towards outliers" which I have always found and experimented to be true : discard outliers IF and ONLY IF they must be really rejected.

It certainly remains some kind of personal choice here - and it always will - BUT - unless you have identified an imperious reason for any particular sight to qualify as an "outlier" and to be "treated" accordingly - then even what seems an "outlier" at a first glance has something to bring to you in terms of overall accuracy and confidence towards your overall CelNav fix.

*******

Peter, one month ago, in your post referenced here-after :

http://www.fer3.com/arc/m2.aspx?i=114585&y=201012
[NavList] Re: Accuracy of sextant observations at sea
From: piterr11---com
Date: 1 Dec 2010 19:40

you kindly pointed our attention towards a paper by M. David Burch to be then found there (and still there to-day) :

http://www.starpath.com/resources2/sight_average.pdf

This article gives a quite interesting example of slope adjustment on the very same data set.

In my subsequent comment to this article in a post referenced here-after :

http://www.fer3.com/arc/m2.aspx?i=114632&y=201012
[NavList] Re: Accuracy of sextant observations at sea (Mr David Burch's ARTICLE on "Averaging Celestial Sights")
From: antoine.m.couette---fr
Date: 4 Dec 2010 22:38

... what I then (kind of) "questioned" about this article is that - given the actual order of magnitude of the given data set dispersion which certainly was far from running totally "wild" - the Author seems to attempt into getting us convinced that there DEFINITELY WAS ONE OUTLIER in his specific example data set, and EVEN MORE that such outlier was certainly not the first one we would have spotted at first.

I am sure - and so would also Geoffrey probably think - that in this specific data set, definitely there was not in this paper any single example of any "flashing outlier" by any reasonable and long practice proven standard.

And certainly this article does not give us a truly convincing example of our practical recipe : "discard outliers IF and ONLY IF they must be really rejected."

*******

One other point for you Peter : you keep reminding us about the great importance of the "calculated slope" as a practical tool to "best evaluate" the quality of data, and - probably also as I would guess - to subsequently single out "outliers".

May I comment one last time on this ?

Once flashing outliers have been treated (i.e. either transformed for obvious typo reasons - such as our (at least "my") all too frequent hand-copying errors which you rightly mentionned earlier - or for such "outliers" to be just simply dumped overboard), the ONLY definite advantage of calculating any slope will show up only if you need one LOP calculated for one specific UT in order to give you a specific azimut LOP (e.g. E or W as you indicated).

Apart from that particular case - which again may often arise for some quite valid and specific needs - there is very little practical interest (especially if you are working under high time pressure) and no need whatsoever - BUT no "ban" either ... - to specifically draw and/or compute any least square line adjustment to your data, whether with the "plain" observed data slope, or even with any "precomputed/predicted" data slope consistent with your environmental position knowledge.

WHY SO ? Quite simply for the reason earlier indicated by some very charitable NavList Member (thanks to you, and I confess that I forgot WHO you are, since anyway this fact had escaped from my mind then) :

ANY AND ALL LEAST SQUARE LINEAR FIT LINE WILL ALWAYS GO THROUGH (i.e. "PIVOT") AROUND THE POINT DEPICTING THE POSITION OF THE MEAN VALUES OF BOTH THE UT's AND HEIGHTS DATA.

In other words, if you simply use Mean Values of both your UT's and Heights data for each set of observations on any single Body, then you are NEVER dropping any part of your data accuracy. It took me a few years of experiment to test and fully validate this practice in the early 80's, and that is also one very good reason why - once "flashing outliers" have been treated according to the preset rules - I have dropped all kinds of manual line drawing computations using whatever slope (whether "predicted" or "observed") and why I eventually have resorted since to only the plain data set averages.

*******

IN THE LONG RUN, YOU WILL NOT GET ANY SUPERIOR RESULTS WITH ANY KIND OF MANUAL "LINE DRAWING" THAN WITH :

- DEFINING YOUR OWN RULES FOR FLASHING OUTLIERS, AND STRICTLY STICKING TO THEM, AND
- FOR EACH BODY OBSERVATIONS SET - AND ONCE FLASHING OUTLIERS IDENTIFIED AND TREATED ACCORDINGLY - USING THEIR PLAIN AVERAGED VALUES FOR BOTH UT AND HEIGHTS.

*******

Our Dear Jeremy - who seems to be one of the few of us being 100% LOP current - does not seem to express any kind of a different view-point when he stated just a few weeks ago that - by comparison to any other kind of (manually) data processing procedure - and for reliability and consistency reasons he always prefers and favors in the long run his "day in and day out" Computer processed CelNav Fixes when compared to his GPS fixes.

And I am guessing that Jeremy's Computer Software is definitely crunching data with a good and solid Least Square Algorithm in order to feed him and - above all ... - his Skipper with our now "beloved "symmedian point".

Best Regards to you all

Kermit

Antoine M. Couëtte
----------------------------------------------------------------
NavList message boards and member settings: www.fer3.com/NavList
Members may optionally receive posts by email.
To cancel email delivery, send a message to NoMail[at]fer3.com
----------------------------------------------------------------