CoCoA » CoCoALib

I noticed the problem while using a simple program to look for ideals where it was costly to compute the RGB of the radical.

I do have a vague recollection that I changed the code which checks for timeout, so that it calls CpuTime only rarely; perhaps too rarely?

I was thinking of an alternative approach since the timeout mechanism is applied in so different cases:
The interval should adapt to the expected time of a single loop. If the estimate is small (<0.001s?), increment the interval (to minimize overhead), if big decrease the interval (giving better estimates with relatively small overhead).
Maybe it already does that?

Of course an input from the user for the first interval size would help for an optimal start.

Reply to comment 6:
yes, CpuTimeLimit does already attempt to adapt automatically. I'm discussing (with myself?) some improvements in issue #1377.

The main problem with checking for timeout during GB computation is that the times for each single reduction can vary enormously (fast may be just a few microsecs, long could be 10+ secs).

I think it may be appropriate to put a check for time-out even inside the reduction code (with the hope that the extra overhead incurred is negligible). It is also true that each single step of the reduction can have quite widely varying times, but I'm hoping the variation is not so pronounced).

I have not yet made any experiments.

I have just spent quite a while trying to work out where I could insert a time-out check inside the reduction code.
TBH I failed to work out which part of the code is relevant :-(
[perhaps someone else can have a look?]

John Abbott wrote:

I have just spent quite a while trying to work out where I could insert a time-out check inside the reduction code.
TBH I failed to work out which part of the code is relevant :-(
[perhaps someone else can have a look?]

I will

What is the status of this issue?

Why are there no test cases for this issue? Without them how can i know if it has been satisfactorily solved?

Using the "french students' example" it seems that this has not been satisfactorily solved :-(

use QQ[x,y,z],Lex;
I := ideal(x^2*y*z + x*y^3*z - 1, x^4*y*z - 1 , x*y^4 + x*y*z-1 );
SetVerbosityLevel(100);
t0 := CpuTime(); GB := GBasisTimeout(I, 30); println "Intr after ", TimeFrom(t0);
--> printed out 95s

Taking more than 3 times as long as requested is disappointing (but perhaps not wholly unacceptable).

What to do?

Setting the timeout to 20s worked very well. Setting it to 25s triggered an interruption after 95s.
Setting it to 97s triggered an interruption after >900s

I must investigate further; this is not really acceptable.

The relevant source is probably in SparsePolyOps-reduce.C around line 133.

The timer object is constructed in *BuiltinFunctions-CoCoALib.C around line 567.

Now I think it should be possible to make CpuTimeLimit check the time more frequently without much overhead (by checking ElapsedTime rather than CpuTime for most checks).
This should avoid the problems reported here.

I have added a new issue (#1558) for exploring this idea.