MD
Magnus Danielson
Mon, Jan 18, 2010 2:29 AM
Dear fellow time-nuts,
In my effort to implement the suite of ADEV and friends, I have been
implementing various forms of them along with the 1000 frequency sample
test sequence out of NIST SP1065:
http://tf.nist.gov/timefreq/general/pdf/2220.pdf
However, I seem to be unable to perfectly match the numbers for the MTotDev.
My numbers so far:
m = 1 m = 10 m = 100
Max 0.9957452943 0.7003371204 0.5489367785
Min 0.0013717599 0.2545924150 0.4533354120
Avg 0.4897744629 0.4897744629 0.4897744629
Sdev 0.2884663647 0.0929635201 0.0320665644
NAdev 0.2922318781 0.0996573606 0.0389780433
OSAdev 0.2922318781 0.0915995342 0.0324134303
OAdev 0.2922318781 0.0915995342 0.0324134303
MAdev 0.2922318781 0.0617237638 0.0217092091
Tdev 0.1687201535 0.3563623166 1.2533817739
Hdev 0.2943883291 0.1052754194 0.0391086056
OHdev 0.2943883291 0.0958108317 0.0323763825
MHdev 0.2942275231 0.0621023549 0.0213087110
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
I have been using both SP1065 and the original article as reference:
http://tf.nist.gov/general/pdf/1369.pdf
I've put care into ensuring that I implement it as close to these as
possible, but with no luck in fixing the numbers.
I use the averaging of the two half-ranges of the 3m block tecnique
rather than the minimum square estimator as recommended. The formulation
given may seem strange, but it is the 3/2m sample average of the
f(i)=(x[n+3/2m+i)-x[n+i])/ (3/2m)
frequency estimation where i varies from 0 to 3/2*m-1.
I have already verified my test-sequence and the numbers produced by the
other algorithms have been able to match after removing various bugs. An
independent implementation may be a good clue.
An alternative may be that the published numbers is incorrect for some
reason, but I don't have sufficient proof for that.
I have however made two different implementation variants that crunch
out the same numbers.
Cheers,
Magnus
Dear fellow time-nuts,
In my effort to implement the suite of ADEV and friends, I have been
implementing various forms of them along with the 1000 frequency sample
test sequence out of NIST SP1065:
http://tf.nist.gov/timefreq/general/pdf/2220.pdf
However, I seem to be unable to perfectly match the numbers for the MTotDev.
My numbers so far:
m = 1 m = 10 m = 100
Max 0.9957452943 0.7003371204 0.5489367785
Min 0.0013717599 0.2545924150 0.4533354120
Avg 0.4897744629 0.4897744629 0.4897744629
Sdev 0.2884663647 0.0929635201 0.0320665644
NAdev 0.2922318781 0.0996573606 0.0389780433
OSAdev 0.2922318781 0.0915995342 0.0324134303
OAdev 0.2922318781 0.0915995342 0.0324134303
MAdev 0.2922318781 0.0617237638 0.0217092091
Tdev 0.1687201535 0.3563623166 1.2533817739
Hdev 0.2943883291 0.1052754194 0.0391086056
OHdev 0.2943883291 0.0958108317 0.0323763825
MHdev 0.2942275231 0.0621023549 0.0213087110
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
I have been using both SP1065 and the original article as reference:
http://tf.nist.gov/general/pdf/1369.pdf
I've put care into ensuring that I implement it as close to these as
possible, but with no luck in fixing the numbers.
I use the averaging of the two half-ranges of the 3*m block tecnique
rather than the minimum square estimator as recommended. The formulation
given may seem strange, but it is the 3/2*m sample average of the
f(i)=(x[n+3/2*m+i)-x[n+i])/ (3/2*m)
frequency estimation where i varies from 0 to 3/2*m-1.
I have already verified my test-sequence and the numbers produced by the
other algorithms have been able to match after removing various bugs. An
independent implementation may be a good clue.
An alternative may be that the published numbers is incorrect for some
reason, but I don't have sufficient proof for that.
I have however made two different implementation variants that crunch
out the same numbers.
Cheers,
Magnus
TV
Tom Van Baak
Mon, Jan 18, 2010 4:23 PM
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
HTOTdev 0.2093297293 0.0958776504 0.0305163951
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
Almost but not quite; Stable32 gives:
Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
I don't use total deviation here myself but I'll look into it for you.
/tvb
> TOTdev 0.2922318781 0.0913474326 0.0340653025
> MTOTdev 0.2303857898 0.0555288598 0.0195467513
> HTOTdev 0.2093297293 0.0958776504 0.0305163951
> The MTOTdev numbers according to page 118 (of PDF, page number 108
> according to the printed pagenumbers) should be
>
> Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
>
> Do anyone happend to have an implementation (in source) of MTOTdev at
> hand giving the NIST SP1065 numbers?
>
> Please note that W. Riley has about the same document in his Handbook,
> and it reflects the same number. I would also suspect that a STABLE32
> run would give those numbers.
Almost but not quite; Stable32 gives:
Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
I don't use total deviation here myself but I'll look into it for you.
/tvb
MD
Magnus Danielson
Tue, Jan 19, 2010 3:10 AM
Hi!
Just to let people know...
Tom Van Baak wrote:
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
HTOTdev 0.2093297293 0.0958776504 0.0305163951
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
Almost but not quite; Stable32 gives:
Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
I don't use total deviation here myself but I'll look into it for you.
With the kind assistance of Tom, we where able to get the answer. The
values given as results in the table on page 118 of NIST SP1065 had been
bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
correlated with that table for MTOTDEV and TTOTDEV.
I can now continue with other algorithms.
Many thanks goes to Tom and for Bill Riley to provide the answer!
Cheers,
Magnus
Hi!
Just to let people know...
Tom Van Baak wrote:
>> TOTdev 0.2922318781 0.0913474326 0.0340653025
>> MTOTdev 0.2303857898 0.0555288598 0.0195467513
>> HTOTdev 0.2093297293 0.0958776504 0.0305163951
>
>> The MTOTdev numbers according to page 118 (of PDF, page number 108
>> according to the printed pagenumbers) should be
>>
>> Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
>>
>> Do anyone happend to have an implementation (in source) of MTOTdev at
>> hand giving the NIST SP1065 numbers?
>>
>> Please note that W. Riley has about the same document in his Handbook,
>> and it reflects the same number. I would also suspect that a STABLE32
>> run would give those numbers.
>
> Almost but not quite; Stable32 gives:
>
> Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
> Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
> Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
>
> I don't use total deviation here myself but I'll look into it for you.
With the kind assistance of Tom, we where able to get the answer. The
values given as results in the table on page 118 of NIST SP1065 had been
bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
correlated with that table for MTOTDEV and TTOTDEV.
I can now continue with other algorithms.
Many thanks goes to Tom and for Bill Riley to provide the answer!
Cheers,
Magnus
JM
John Miles
Tue, Jan 19, 2010 5:49 AM
If you'd like to make the C source available, I'll look at building an
incremental version...?
-- john, KE5FX
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
Behalf Of Magnus Danielson
Sent: Monday, January 18, 2010 7:10 PM
To: Tom Van Baak; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Modified Total Deviation calculation
Hi!
Just to let people know...
Tom Van Baak wrote:
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
HTOTdev 0.2093297293 0.0958776504 0.0305163951
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
Almost but not quite; Stable32 gives:
Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
I don't use total deviation here myself but I'll look into it for you.
With the kind assistance of Tom, we where able to get the answer. The
values given as results in the table on page 118 of NIST SP1065 had been
bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
correlated with that table for MTOTDEV and TTOTDEV.
I can now continue with other algorithms.
Many thanks goes to Tom and for Bill Riley to provide the answer!
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
If you'd like to make the C source available, I'll look at building an
incremental version...?
-- john, KE5FX
> -----Original Message-----
> From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
> Behalf Of Magnus Danielson
> Sent: Monday, January 18, 2010 7:10 PM
> To: Tom Van Baak; Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Modified Total Deviation calculation
>
>
> Hi!
>
> Just to let people know...
>
> Tom Van Baak wrote:
> >> TOTdev 0.2922318781 0.0913474326 0.0340653025
> >> MTOTdev 0.2303857898 0.0555288598 0.0195467513
> >> HTOTdev 0.2093297293 0.0958776504 0.0305163951
> >
> >> The MTOTdev numbers according to page 118 (of PDF, page number 108
> >> according to the printed pagenumbers) should be
> >>
> >> Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
> >>
> >> Do anyone happend to have an implementation (in source) of MTOTdev at
> >> hand giving the NIST SP1065 numbers?
> >>
> >> Please note that W. Riley has about the same document in his Handbook,
> >> and it reflects the same number. I would also suspect that a STABLE32
> >> run would give those numbers.
> >
> > Almost but not quite; Stable32 gives:
> >
> > Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
> > Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
> > Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
> >
> > I don't use total deviation here myself but I'll look into it for you.
>
> With the kind assistance of Tom, we where able to get the answer. The
> values given as results in the table on page 118 of NIST SP1065 had been
> bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
> correlated with that table for MTOTDEV and TTOTDEV.
>
> I can now continue with other algorithms.
>
> Many thanks goes to Tom and for Bill Riley to provide the answer!
>
> 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.
MD
Magnus Danielson
Tue, Jan 19, 2010 10:17 AM
If you'd like to make the C source available, I'll look at building an
incremental version...?
If you can accept the current quick-hack state of the code (yes, I am
not too proud of the cleanness, so no comments about coding style or the
general uglyness), find it attached. The main goal of this code is
correctness. Find it attached.
I'll hacking away further.
An incremental version is a trivial extention for MTOTDEV as the outer
loop steps the 3m sample window over the data-samples. So you need to
keep a 3m big backlog of samples for the largest m you need. For
simplicity I made the expantion into the 9m series explicit and with a
3m offset from the index of the original data only for clarity while
debugging the code. Some of that debugging was not in the core
algorithm, but in the missing 0.73 factor, which is the bias factor for
white FM noise. A good quality measure would adjust the bias factor
based on the dominant noise-source, but that comes as later refinement.
Anyway, hope you find the code usefull. Will hack away to make more
values calculated. Currently the Hadamard Total Deviation is not
correct, as a quick-check with SP1065 page 118 would tell you. But that
was a quick-hack anyway.
Oh, yes... among the particular uglyness issues is that the routines
know just how many samples the time or frequency sample series contains.
Ugly as hell, but for the intended purpose (known test-series) that is ok.
Cheers,
Magnus
John Miles wrote:
> If you'd like to make the C source available, I'll look at building an
> incremental version...?
If you can accept the current quick-hack state of the code (yes, I am
not too proud of the cleanness, so no comments about coding style or the
general uglyness), find it attached. The main goal of this code is
correctness. Find it attached.
I'll hacking away further.
An incremental version is a trivial extention for MTOTDEV as the outer
loop steps the 3*m sample window over the data-samples. So you need to
keep a 3*m big backlog of samples for the largest m you need. For
simplicity I made the expantion into the 9*m series explicit and with a
3*m offset from the index of the original data only for clarity while
debugging the code. Some of that debugging was not in the core
algorithm, but in the missing 0.73 factor, which is the bias factor for
white FM noise. A good quality measure would adjust the bias factor
based on the dominant noise-source, but that comes as later refinement.
Anyway, hope you find the code usefull. Will hack away to make more
values calculated. Currently the Hadamard Total Deviation is not
correct, as a quick-check with SP1065 page 118 would tell you. But that
was a quick-hack anyway.
Oh, yes... among the particular uglyness issues is that the routines
know just how many samples the time or frequency sample series contains.
Ugly as hell, but for the intended purpose (known test-series) that is ok.
Cheers,
Magnus
JA
John Ackermann N8UR
Tue, Jan 19, 2010 1:13 PM
I see the makings of a great project here... a standard set of routines
for time/frequency/stability statistics. My only request is to code
unobfuscatedly (sp?) to make translation into other languages easier
(e.g., I'd love a perl module with these functions, but am a complete
schmoe at figuring out C).
John
John Miles wrote:
If you'd like to make the C source available, I'll look at building an
incremental version...?
-- john, KE5FX
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
Behalf Of Magnus Danielson
Sent: Monday, January 18, 2010 7:10 PM
To: Tom Van Baak; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Modified Total Deviation calculation
Hi!
Just to let people know...
Tom Van Baak wrote:
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
HTOTdev 0.2093297293 0.0958776504 0.0305163951
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
Almost but not quite; Stable32 gives:
Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
I don't use total deviation here myself but I'll look into it for you.
With the kind assistance of Tom, we where able to get the answer. The
values given as results in the table on page 118 of NIST SP1065 had been
bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
correlated with that table for MTOTDEV and TTOTDEV.
I can now continue with other algorithms.
Many thanks goes to Tom and for Bill Riley to provide the answer!
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
I see the makings of a great project here... a standard set of routines
for time/frequency/stability statistics. My only request is to code
unobfuscatedly (sp?) to make translation into other languages easier
(e.g., I'd love a perl module with these functions, but am a complete
schmoe at figuring out C).
John
----
John Miles wrote:
> If you'd like to make the C source available, I'll look at building an
> incremental version...?
>
> -- john, KE5FX
>
>> -----Original Message-----
>> From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
>> Behalf Of Magnus Danielson
>> Sent: Monday, January 18, 2010 7:10 PM
>> To: Tom Van Baak; Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Modified Total Deviation calculation
>>
>>
>> Hi!
>>
>> Just to let people know...
>>
>> Tom Van Baak wrote:
>>>> TOTdev 0.2922318781 0.0913474326 0.0340653025
>>>> MTOTdev 0.2303857898 0.0555288598 0.0195467513
>>>> HTOTdev 0.2093297293 0.0958776504 0.0305163951
>>>> The MTOTdev numbers according to page 118 (of PDF, page number 108
>>>> according to the printed pagenumbers) should be
>>>>
>>>> Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
>>>>
>>>> Do anyone happend to have an implementation (in source) of MTOTdev at
>>>> hand giving the NIST SP1065 numbers?
>>>>
>>>> Please note that W. Riley has about the same document in his Handbook,
>>>> and it reflects the same number. I would also suspect that a STABLE32
>>>> run would give those numbers.
>>> Almost but not quite; Stable32 gives:
>>>
>>> Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
>>> Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
>>> Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
>>>
>>> I don't use total deviation here myself but I'll look into it for you.
>> With the kind assistance of Tom, we where able to get the answer. The
>> values given as results in the table on page 118 of NIST SP1065 had been
>> bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
>> correlated with that table for MTOTDEV and TTOTDEV.
>>
>> I can now continue with other algorithms.
>>
>> Many thanks goes to Tom and for Bill Riley to provide the answer!
>>
>> 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.
>
>
> _______________________________________________
> 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.
PK
Poul-Henning Kamp
Tue, Jan 19, 2010 1:37 PM
My only request is to code unobfuscatedly [...]
Well, there is a tendency for unobfuscated versions of these functions
to suffer from rounding errors, in particular when absolute timestamps
are used.
Please pay particular attention to this, as the rounding losses tend
to result in overly optimistic, but often almost plausible metrics.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message <4B55AFE9.4040104@febo.com>, John Ackermann N8UR writes:
>My only request is to code unobfuscatedly [...]
Well, there is a tendency for unobfuscated versions of these functions
to suffer from rounding errors, in particular when absolute timestamps
are used.
Please pay particular attention to this, as the rounding losses tend
to result in overly optimistic, but often almost plausible metrics.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
DJ
Didier Juges
Tue, Jan 19, 2010 2:15 PM
Perl is well supported under Windows and all flavors of *nix. That would be a good choice in my opinion.
You can write Perl code that looks an awful lot like C, or you can make it extremely cryptic and obfuscated for a C programmer.
One thing I love in Perl is regex. Not much equivalent under any other Windows tool that I am familiar with. I am not sure why you would need regex for that though.
Only problem (for me) is that of the GUI. I have not done GUIs in Perl (aside from generating html code), but I can see a standalone executable that would take a file in, and produce a file out, and you can use your favorite language to display the results.
Didier KO4BB
------------------------ Sent from my BlackBerry Wireless thingy while I do other things...
-----Original Message-----
From: John Ackermann N8UR jra@febo.com
Date: Tue, 19 Jan 2010 08:13:13
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Subject: Re: [time-nuts] Modified Total Deviation calculation
I see the makings of a great project here... a standard set of routines
for time/frequency/stability statistics. My only request is to code
unobfuscatedly (sp?) to make translation into other languages easier
(e.g., I'd love a perl module with these functions, but am a complete
schmoe at figuring out C).
John
John Miles wrote:
If you'd like to make the C source available, I'll look at building an
incremental version...?
-- john, KE5FX
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
Behalf Of Magnus Danielson
Sent: Monday, January 18, 2010 7:10 PM
To: Tom Van Baak; Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Modified Total Deviation calculation
Hi!
Just to let people know...
Tom Van Baak wrote:
TOTdev 0.2922318781 0.0913474326 0.0340653025
MTOTdev 0.2303857898 0.0555288598 0.0195467513
HTOTdev 0.2093297293 0.0958776504 0.0305163951
The MTOTdev numbers according to page 118 (of PDF, page number 108
according to the printed pagenumbers) should be
Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
Do anyone happend to have an implementation (in source) of MTOTdev at
hand giving the NIST SP1065 numbers?
Please note that W. Riley has about the same document in his Handbook,
and it reflects the same number. I would also suspect that a STABLE32
run would give those numbers.
Almost but not quite; Stable32 gives:
Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
I don't use total deviation here myself but I'll look into it for you.
With the kind assistance of Tom, we where able to get the answer. The
values given as results in the table on page 118 of NIST SP1065 had been
bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
correlated with that table for MTOTDEV and TTOTDEV.
I can now continue with other algorithms.
Many thanks goes to Tom and for Bill Riley to provide the answer!
Cheers,
Magnus
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
Perl is well supported under Windows and all flavors of *nix. That would be a good choice in my opinion.
You can write Perl code that looks an awful lot like C, or you can make it extremely cryptic and obfuscated for a C programmer.
One thing I love in Perl is regex. Not much equivalent under any other Windows tool that I am familiar with. I am not sure why you would need regex for that though.
Only problem (for me) is that of the GUI. I have not done GUIs in Perl (aside from generating html code), but I can see a standalone executable that would take a file in, and produce a file out, and you can use your favorite language to display the results.
Didier KO4BB
------------------------ Sent from my BlackBerry Wireless thingy while I do other things...
-----Original Message-----
From: John Ackermann N8UR <jra@febo.com>
Date: Tue, 19 Jan 2010 08:13:13
To: Discussion of precise time and frequency measurement<time-nuts@febo.com>
Subject: Re: [time-nuts] Modified Total Deviation calculation
I see the makings of a great project here... a standard set of routines
for time/frequency/stability statistics. My only request is to code
unobfuscatedly (sp?) to make translation into other languages easier
(e.g., I'd love a perl module with these functions, but am a complete
schmoe at figuring out C).
John
----
John Miles wrote:
> If you'd like to make the C source available, I'll look at building an
> incremental version...?
>
> -- john, KE5FX
>
>> -----Original Message-----
>> From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
>> Behalf Of Magnus Danielson
>> Sent: Monday, January 18, 2010 7:10 PM
>> To: Tom Van Baak; Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Modified Total Deviation calculation
>>
>>
>> Hi!
>>
>> Just to let people know...
>>
>> Tom Van Baak wrote:
>>>> TOTdev 0.2922318781 0.0913474326 0.0340653025
>>>> MTOTdev 0.2303857898 0.0555288598 0.0195467513
>>>> HTOTdev 0.2093297293 0.0958776504 0.0305163951
>>>> The MTOTdev numbers according to page 118 (of PDF, page number 108
>>>> according to the printed pagenumbers) should be
>>>>
>>>> Modified Total Dev 2.418528e-01 6.499161e-02 2.287774e-02
>>>>
>>>> Do anyone happend to have an implementation (in source) of MTOTdev at
>>>> hand giving the NIST SP1065 numbers?
>>>>
>>>> Please note that W. Riley has about the same document in his Handbook,
>>>> and it reflects the same number. I would also suspect that a STABLE32
>>>> run would give those numbers.
>>> Almost but not quite; Stable32 gives:
>>>
>>> Tot Dev (1,10,100) 2.9223e-01, 9.1347e-02, 3.4065e-02
>>> Mod Tot Dev (1,10,100) 2.0664e-01, 5.5529e-02, 1.9547e-02
>>> Had Tot Dev (1,10,100) 2.9439e-01, 9.6148e-02, 3.0504e-02
>>>
>>> I don't use total deviation here myself but I'll look into it for you.
>> With the kind assistance of Tom, we where able to get the answer. The
>> values given as results in the table on page 118 of NIST SP1065 had been
>> bias-adjusted with 1/sqrt(0.73) to overcome the bias. My numbers now
>> correlated with that table for MTOTDEV and TTOTDEV.
>>
>> I can now continue with other algorithms.
>>
>> Many thanks goes to Tom and for Bill Riley to provide the answer!
>>
>> 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.
>
>
> _______________________________________________
> 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.
_______________________________________________
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.
MD
Magnus Danielson
Tue, Jan 19, 2010 5:47 PM
John Ackermann N8UR wrote:
I see the makings of a great project here... a standard set of routines
for time/frequency/stability statistics. My only request is to code
unobfuscatedly (sp?) to make translation into other languages easier
(e.g., I'd love a perl module with these functions, but am a complete
schmoe at figuring out C).
Have you looked at the code? Is it cryptic?
I have no reason to make it cryptic, my drive for the current phase is
correctness and that calls for clarity. Have a look at the formulas and
associated text alongside it as well. The modified total and Hadamard
total deviations are the most picky ones so far. Running the
test-sequence for correctness-testing of implementation is a another
help, as it will hint you on errors, like looping an element too much or so.
Cheers,
Magnus
John Ackermann N8UR wrote:
> I see the makings of a great project here... a standard set of routines
> for time/frequency/stability statistics. My only request is to code
> unobfuscatedly (sp?) to make translation into other languages easier
> (e.g., I'd love a perl module with these functions, but am a complete
> schmoe at figuring out C).
Have you looked at the code? Is it cryptic?
I have no reason to make it cryptic, my drive for the current phase is
correctness and that calls for clarity. Have a look at the formulas and
associated text alongside it as well. The modified total and Hadamard
total deviations are the most picky ones so far. Running the
test-sequence for correctness-testing of implementation is a another
help, as it will hint you on errors, like looping an element too much or so.
Cheers,
Magnus
JA
John Ackermann N8UR
Tue, Jan 19, 2010 5:55 PM
No, I posted before I saw your example (and still haven't had a chance
to look at it closely). I'm just hoping that in the end we can end up
with a set of functions that can readily be ported to other languages,
and if I'm going to be able to participate in that, I need all the help
I can get! (I'm not a natural programmer, and C has always been
challenging for me.)
John
Magnus Danielson wrote:
John Ackermann N8UR wrote:
I see the makings of a great project here... a standard set of
routines for time/frequency/stability statistics. My only request is
to code unobfuscatedly (sp?) to make translation into other languages
easier (e.g., I'd love a perl module with these functions, but am a
complete schmoe at figuring out C).
Have you looked at the code? Is it cryptic?
I have no reason to make it cryptic, my drive for the current phase is
correctness and that calls for clarity. Have a look at the formulas and
associated text alongside it as well. The modified total and Hadamard
total deviations are the most picky ones so far. Running the
test-sequence for correctness-testing of implementation is a another
help, as it will hint you on errors, like looping an element too much or
so.
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.
No, I posted before I saw your example (and still haven't had a chance
to look at it closely). I'm just hoping that in the end we can end up
with a set of functions that can readily be ported to other languages,
and if I'm going to be able to participate in that, I need all the help
I can get! (I'm not a natural programmer, and C has always been
challenging for me.)
John
----
Magnus Danielson wrote:
> John Ackermann N8UR wrote:
>> I see the makings of a great project here... a standard set of
>> routines for time/frequency/stability statistics. My only request is
>> to code unobfuscatedly (sp?) to make translation into other languages
>> easier (e.g., I'd love a perl module with these functions, but am a
>> complete schmoe at figuring out C).
>
> Have you looked at the code? Is it cryptic?
>
> I have no reason to make it cryptic, my drive for the current phase is
> correctness and that calls for clarity. Have a look at the formulas and
> associated text alongside it as well. The modified total and Hadamard
> total deviations are the most picky ones so far. Running the
> test-sequence for correctness-testing of implementation is a another
> help, as it will hint you on errors, like looping an element too much or
> so.
>
> 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.