> < ^ Date: Mon, 08 Jul 1996 16:21:00 +0100 (MET)
> < ^ From: Martin Schoenert <martin.schoenert@math.rwth-aachen.de >
^ Subject: Runtime function

David Wood asked the following question on 'GAP-Trouble'

I recently executed the following GAP code on a Sun Sparcstation:
a := Runtime();
# do something else (which took a number of days)
b := Runtime() - a;
At this stage b = -417725315.
I expect this was as a result of some overflow error.
Is it possible to calculate what the actual value should be?

Since this may be of interest to other GAP users as well,
allow me to answer this question in the GAP forum.

'Runtime' returns the time as a small integer.
It does not check wether the time will actually fit into 28 bits.

That means that for 2^28 milliseconds (~3 days/2 hours/34 minutes)
everything works fine.

For the next 2^28 milliseconds 'Runtime' returns positive integers
in the range 2^28..2^29-1. The problem is that 'Runtime' returns
such integers as *small* positive integers, while the rest of GAP
represents such integers as *large* positive integers. When one
does arithmetic with such integers, GAP can not reliably detect
overflow any more. The solution is to ``renomalize'' such integers
by adding '0' to them first.

For the next 2^28 milliseconds 'Runtime' returns negative integers
in the range -2^29..-2^28-1. Again 'Runtime' returns such integers
as small negative integers, but they should be represented as large
negative integers. Again ``renomalizing'' helps.

For the next 2^28 milliseconds 'Runtime' returns negative integers
in the range -2^28..-1.

After 2^30 milliseconds (~ 12 days/10 hours/16 minutes) the whole
cycle starts all over again.

Since the reported value 'b = -417725315' lies between -2^29..-2^28-1
we renomalize it first,
gap> bb := b + 0;

It corresponds to

gap> StringTime( bb + 2^30 );
# 7 days/14 hours/13 minutes/36 seconds/509 milliseconds

or, if the timer wrapped around once, to

gap> StringTime( bb + 2 * 2^30 );
# 20 days/0 hours/29 minutes/18 seconds/333 milliseconds

and so on.

So if you know the runtime roughly (i.e. with 2 weeks precision),
you can recompute the true runtime.

Hope this helps,


-- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,   +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany

> < [top]