Maybe R11 had tic/toc with options (as reported above), I don’t remember. However, R13 does NOT.
So take care if you must guarantee downward compatibility.

Version compatibility issue(2):

@Alessandro Giusti:
>> uint64(1)+uint64(2)
??? Undefined function or method ‘plus’ for input arguments of type ‘uint64′.
Why?!?

Response: help text says: UINT64 is primarily meant to store integer values, and math operations are
NOT defined since they are ambiguous on the boundary of the set (e.g., wrap or truncate there)
UINT32 has (had?) less but essentially similar restrictions, for good reasons.

I recognized some inconsistencies between UINT8/16/32/64 regarding the allowed basic math operations
(plus, times). Math support has been improved in versions after R13 but seems still kind of crappy and
–my personal opinion– even more inconsistent than in R13. Depending on the Matlab version, stuff like
uint32(32)+double(rand) can yield errors or uint32(round(32+rand)), i.e., one can neither rely on errors
nor expect an implicit type conversion to double as in C/C++

Frankly, I dont care any longer whether this has changed in new releases — I simply avoid uint classes
completely except for raw binary file IO or to check input arguments, e.g., using isequal(x,uint16(x)).

And regarding the use of uint64 as a counter/hashcode/handle: just try

>> tic, for n=1:2^16, k=uint64(n); end; toc

and extrapolate the number of days required until the loop would stop for n=1:2^64.

I guess that toc apparently returns UINT64 not because 64 bit precision were technically necessary
or would simplify follow-up operations in Matlab, but rather because UINT64 is what Java or OS library
functions natively return to Matlab, and because Matlab’s tic/toc do not want to waste any time for
type conversion and out-of-range checking/mapping. This leads me to the conclusion that tic/toc should
be potentially more precise than t0=now; … dt=now-t0; because NOW definitely requires some algorithmic
overhead.

Can anybody (in)validate these conclusions?

Cheers, H;

for i = 1:2:10;
   t0 = double(tic);
   pause(i); 
   t1 = double(tic); 
   dt = t1-t0; 
   per_sec = dt./i; 
   fprintf('dt = %g   per_sec = %g\n', dt, per_sec); 
end

That results in about 2.84e+009, 3.0e+009 and 3.15e+009 “tic units” per second on the 2.83, 3.0 and 3.16 GHz Windows XP and Server 2003 machines I tested it on.

Plug in your machine’s clock speed and you get the uptime.

ghz = 3.0; uptime = round(double(tic) ./ (ghz * 10^9 * 60))

TIC sets a local persistent variable to the current time. TOC returns the difference between that time and the current time. The value T=TIC just returns the current time, without resetting the local variable. TOC(T) then returns the difference between T and the current time. If T is larger than the current time, it uses the local variable. That is, it ignores its input. How the “current time” is defined could depend on the system, though. I wouldn’t count on it being the time since the computer last rebooted.

Oh, I should have checked earlier. I’m just now looking at HELP TIC and HELP TOC. This feature is documented in R2009a.

>> [a,retv_pre] = system(‘date +”%s”’);ticv = tic();[a,retv_post] = system(‘date +”%s”’);retv_avg = 0.5 * (str2num(retv_pre) + str2num(retv_post));retv_avg – (double(ticv) / 1e6)

ans =

-0.5501

The usual behavior of other functions, instead, made me initially think of the value being some sort of handle to internal data, which is probably not.

This is confirmed by a couple of tests (at least under linux):

>> a=tic; pause(1); b=tic;
>> disp(double(b)-double(a))
1000624

>> a=tic; pause(2); b=tic;
>> disp(double(b)-double(a))
2000627

… and also:
>> a=tic; pause(1); toc(uint64(double(a)+1))
Elapsed time is 1.000410 seconds.

A partly unrelated note:

>> uint64(1)+uint64(2)
??? Undefined function or method ‘plus’ for input arguments of type ‘uint64′.

Why?!?

On my computer, one tic is 6.9836e-008 seconds, according to my measurements. This internal counter starts at 0 when the computer starts.