> < ^ From:

^ Subject:

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; -417725315

It corresponds to

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

or, if the timer wrapped around once, to

gap> StringTime( bb + 2 * 2^30 ); "480:29:18.333" # 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.

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

> < [top]