Prev: convolution matrix
Next: read xls files with name 00000.xls and 00001.xls
From: Jan Simon on 24 Jun 2010 06:12
Dear readers,

I need some nearly random bits to create a nearly unique number equivalent to a GUID. I thought CPUTIME or CLOCK would be fine, but I found some unexpected correlations, when I call this function repeatedly.

% Tested on Matlab 6.5, 2009a, WinXP 32bit
function sillyTest
a = cputime;
v = rand(1000); % Any operation wasting some time
% drawnow; % Waste more arbitrary time, but does not help
b = cputime;
fprintf('%f\n%f\n', a, b);
return;

As expected computing RAND needs some time such that [a] and [b] differ. But the 3rd digit behind the point looks strongly correlated:
>> sillyTest
78.783285
78.883429
>> sillyTest
78.963544
79.083717
>> sillyTest
79.153818
79.253962
The pattern, which caught my attention is 3285, 3429, 3544, 3717, 3818, 3962, ... (I've repeated it over 100 times). I'd expect, that the 1/1000 sec part is almost random.
I have started sillyTest manually from the command window, and I do not think that the precision of my fingers reach 1/1000 of a second. Calling it from a program inserting PAUSE(rand/10) does not change the pattern, but PAUSE has an internal precision of 1/100 sec, and the manual test is more arbitrary, in my opinion.

Using "v = rand(2312)" or any other time consuming function does not influence the pattern in the trailing digits.
Calling CLOCK instead leads to equivalent results, e.g. "c = clock; a = c(6);", but then the precision is limited to 3 figures after the point. Again the 3rd digits (the 1/1000 seconds) look strongly correlated: Subsequent calls reply equal or slowly increasing values!

The best explanation I find is that the CPUTIME and CLOCK ticks have a precision of 1/100 second and the smaller part is "generated" based on a time related value (e.g. the cpu-time used for the current process or the seconds since starting the computer divided by PI), but *not* on the time itself.

When I ask FEATURE for the precision of the clock
feature timing clocks_per_sec
it replies 1000 cycles/sec, therefore I expected, that CLOCK has an equivalent precision.

Another example:
a = clock; b = clock;
while isequal(a, b), b = clock; end
disp([a(6), b(6)])
The 1/1000 second of [a] and [b] are in about 980 of 1000 tests equal. But even if the 1/1000 second differs, the 1/100 second has changed also. This implies, that CLOCK tics with 1/100 sec and proceed the 1/1000 value by a clandestine mechanism.

Can anybody confirm or explain this behaviour?
If the 1/1000 sec part of CLOCK has just a limited meaning, wouldn't it be better to reduce the precision to 1/100 honestly?

My original problem is solved using FEATURE('timing', 'cpucount') and FEATURE('timing', 'wintimeofday'), but this is not documented. TIC is also a good source of some unique bits, but only in Matlab 7.

Thanks for your attention, Jan
From: Steven Lord on 24 Jun 2010 09:40

"Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message
news:hvvb1k$l9m$1(a)fred.mathworks.com...
> Dear readers,
>
> I need some nearly random bits to create a nearly unique number equivalent
> to a GUID. I thought CPUTIME or CLOCK would be fine, but I found some
> unexpected correlations, when I call this function repeatedly.

*snip*

If you need random data, why use CPUTIME or CLOCK? Why not use a function
whose PURPOSE is to generate random data like RAND, RANDN, or RANDI?

--
Steve Lord
slord(a)mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com


From: Jan Simon on 24 Jun 2010 12:19
Dear Steven!

> If you need random data, why use CPUTIME or CLOCK? Why not use a function
> whose PURPOSE is to generate random data like RAND, RANDN, or RANDI?

Thanks for answering.

The main purpose of a GUID is not to be random, but unique. Using a RAND method would not be safe, because a user could set a fixed seed.

My GUID contains several parts: lab-, computer-, user- and PID-related. For a time-related part I'm using a 4 character string, which is (simplified):
D = clock * [0; 0; 0; 360000; 6000; 100];
Symbol = char(['A':'Z', 'a:z', '0':'9', '_']);
Tag = Symbol(1 + rem(fix(D/63^3, D/63^2, D/63, D), 63));
The strange base63 coding allows to use the tag in the names of Matlab functions and variables. The tags are not necessarily unique after 24 hours or if the the delay between the creation of 2 tags is less than 0.01 sec.

As further improvement I tried to include the 1/1000 sec also (and the day of the year) and wait a tiny time until CLOCK changes. But to my surprise the waiting took 0.01 sec ever.

But as said already: My GUID problem is solved already using the CPU cycles and Windows up-time.
I'm just astonished about the nature of the 3rd digit after the dot of CLOCK(6) and CPUTIME. If anybody could reproduce my observations, it is *not* a 1/1000 sec, as a naive physicist like me would expect.

Kind regards, Jan
From: Jan Simon on 25 Jun 2010 10:27
Dear Matlab users,

Obviously the precision of CPUTIME and and CLOCK is not so important for the members of this newsgroup. I'm going to ask the support for an explanation.

Kind regards, Jan
From: us on 25 Jun 2010 11:29
"Jan Simon" <matlab.THIS_YEAR(a)nMINUSsimon.de> wrote in message <i02ebq$1qu$1(a)fred.mathworks.com>...
> Dear Matlab users,
>
> Obviously the precision of CPUTIME and and CLOCK is not so important for the members of this newsgroup. I'm going to ask the support for an explanation.
>
> Kind regards, Jan

here's a bit of information...

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f8-790895.html

us
 |  Next  |  Last
Pages: 1 2
Prev: convolution matrix
Next: read xls files with name 00000.xls and 00001.xls