ADEV vs. OADEV
Bruce,
Tom
Its important to realise these calculated statistics are all estimators
of the underlying Allan variance.
Thus it is important to assign unique unambiguous names to each of them
so that some idea of their region of reasonable accuracy and perhaps
their confidence limits can be estimated.
It should be recalled that AVAR is actually not necessarilly a name as
such but short-hand. To help making the issue complex, AVAR has been
given as a name to denote a particular algorithm, just as MADEV, TDEV
etc. Even if one can argue that they have these meanings within a
specific context, the ambiguity problem is there as it makes it harder
to compare results.
Thus for example:
AVAR doesn't actually denote the underlying Allan variance but rather a
particular algorithm used to estimate it from the data.
OAVAR denotes another algorithm for estimating the underlying Allan
variance from the data
Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others
have already denoted AVAR, thus causing ambiguity.
TOTVAR, THEO1 and THEOH denote other algorithms that can be used to
estimate the underlying Allan variance from the data.
Some of these algorithms produce biased estimates of the underlying
Allan variance so correction for such bias is usually necessary.
The way the confidence interval closes on the estimate should be of a
concern. We can calculate whatever we want, but as we try to judge the
results of such estimates we should also view the indicators of its
precision if available.
Cheers,
Magnus
Bruce,
Bruce Griffiths skrev:
Addendum:
There would appear to be only 3 underlying frequency stability
statistics of interest in this paper:
-
Allan variance
-
Modified Allan variance
-
Hadamard variance
Each of which has a different phase transfer function.
All other statistical quantities related to frequency stability in this
paper are actually estimators of one of the above underlying statistics
Each estimator has different confidence limits and a different bias
function which may depend on phase noise type.
Correction for the underlying bias of each estimator is desirable before
plotting the results.
Confidence limits are also useful.
I agree... very good points.
Cheers,
Magnus
Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others
have already denoted AVAR, thus causing ambiguity.
One can equally say the algorithm you now want to call simply
"AVAR" others long before you chose to call "overlapping AVAR"
in order to clearly distinguish it from the pre-existing label that
you no longer even want to call "AVAR".
Personally I prefer to call it AVAR/ADEV when the implementation
isn't relevant; and in those cases when it is, I specifically qualify
the name with something like "normal" vs. "overlapping". That
removes the ambiguity regardless of historical interpretation.
We've beat this to death now and all understand the issues, yes?
/tvb
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@febo.com
[mailto:time-nuts-bounces@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
and
follow the instructions there.
Tom Van Baak skrev:
Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others
have already denoted AVAR, thus causing ambiguity.
One can equally say the algorithm you now want to call simply
"AVAR" others long before you chose to call "overlapping AVAR"
in order to clearly distinguish it from the pre-existing label that
you no longer even want to call "AVAR".
I think you missed my point... I didn't want to call it that. I notice
that it is already called AVAR.
Personally I prefer to call it AVAR/ADEV when the implementation
isn't relevant; and in those cases when it is, I specifically qualify
the name with something like "normal" vs. "overlapping". That
removes the ambiguity regardless of historical interpretation.
This is a good resolution. I would rather prefer "normal" being replaced
with "original" or something as the context would select which is the
"normal" one, which is a subjective matter.
The definition actually does not result in a particular algorithm (which
popular beleif seems to imply), so one has to be carefull in putting
judgement or preference in the prefix.
We've beat this to death now and all understand the issues, yes?
I think this particular issue is beaten pretty dead by now. I at least
picked up a few important lessons. I hope others did too.
Cheers,
Magnus