Magnus, > So, feel free to short-hand Allan Variance as AVAR, but there are > context in which this is going to be interpreted as being the > overlapping Allan variance estimator and not any other estimator, and > hence using that short-hand can be ambiguous.
Thanks for your insight! And to avoid this ambiguity a single char in front of AVAR like OAVAR and MAVAR serves pretty well. Best regards Ulrich > -----Ursprungliche Nachricht----- > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Magnus Danielson > Gesendet: Freitag, 23. Januar 2009 01:36 > An: Tom Van Baak; Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] ADEV vs. OADEV > > > Tom Van Baak skrev: > >> One point of confusion is that AVAR(tau) should not be directly > >> interpreted as Allan Variance in general, it is actually > already defined > >> and reserved to mean a chosen Allan Variance estimator. This is an > > > > Sorry if I'm jumping into this thread late, but this statement > > confuses me. > > Feel free to join in... > > > Since when is "AVAR" not simply short-hand > > for "Allan Variance"? > > Good question. My point being that yes... AVAR is a handy > short-hand for > Allan Deviation, but it is also actually a standardised quantity and > several standards actually define it consistently as a particular > estimator. It's a good estimator for being of the Allan > Variance family > and CPU-cycles should not prohibit us from using it. > > Recall that they are all estimators. I think this is a > crutial point to > learn really. Once one has accepted that fact, then taking a look at > which estimator serves me the best becomes the issue of interest, not > "which is the right one?" which is actually an incorrect question in > this context. > > So, feel free to short-hand Allan Variance as AVAR, but there are > context in which this is going to be interpreted as being the > overlapping Allan variance estimator and not any other estimator, and > hence using that short-hand can be ambiguous. If we want an > unambiguous > use of AVAR, do not use AVAR as short-hand for Allan Variance > when using > other estimators than the overlapping one. Do as you please, > but now you > are aware of the issue. > > Also, look at the NIST SP 1065 for instance, where it is clearly > indicated that the "original" is being superseded in most > practical use > for the benefit of the overlapping, giving improved confidence > intervals. Also, Modified Allan Variance and Theo should be > considered > as better alternatives. > > The SP 1065 should be a good read for many, as it gives a modern > overview and also addresses several practical implementational issues > such as software test-sequences etc. The TN 1337 is a more > classic view > and collection of articles. > > So... we could argue all we want about "which is the correct Allan > Variance" but it doesn't really help. The original estimator > is flawed. > the overlapping estimator improves confidence and the Theo > family should > provide even better results. > > > Next you'll tell me SDEV isn't Standard Deviation because some > > self-important standards organization decided otherwise. > > I could probably find a standard defining it to something completely > different and totally out of context which would not help. > > But the reaction is natural, but one must realize that there > is not real > "right" here, so sometimes putting down the foot and say > "this is what > we define it to be" is needed so that everyone at least do it > according > to the same procedures and with known errors... until you > realize that > you need something better and move over to some other > measurement which > you define in a similar fashion. It's like say the meter > standard. "This > is the meter... until we say something different". > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
