[time-nuts] ADEV vs. OADEV

Ulrich Bangert df6jb at ulrich-bangert.de
Fri Jan 23 09:03:06 UTC 2009


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: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] 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 -- time-nuts at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> and 
> follow the instructions there.
> 




More information about the time-nuts mailing list