Project

General

Profile

Bug #1705

ProgressReporter: prepare for new loop?

Added by John Abbott over 1 year ago. Updated 13 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
John Abbott
Category:
Improving
Target version:
CoCoALib-0.99880
Start date:
24 Oct 2022
Due date:
% Done:

90%

Estimated time:
Spent time:
2.05 h

Description

I have a program with 3 loops, and would like to have progress info about each loop.
The 1st loop is very fast; the 2nd loop is quite a bit slower; and the 3rd loop is slower still.
All 3 loops do the same number of iterations.

My idea was to use a single ProgressReporter object for all 3 loops,
but it does not report anything for the slower loops.

Fix this!

History

#1 Updated by John Abbott over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

A likely cause is that the frequency of proper time checks is too low (because of the very fast iters of the 1st loop).

Two obvious possible fixes:
  • (A) impose a lower upper bound on the frequency between proper checks
  • (B) offer a PrepareForNewLoop function (similar to CpuTimeLimit)

At the moment I prefer (B) but its does require cooperation from the user.
Maybe I should do both?

Or is the cause other than what I believe?

#2 Updated by Anna Maria Bigatti over 1 year ago

John Abbott wrote:

A likely cause is that the frequency of proper time checks is too low (because of the very fast iters of the 1st loop).

Two obvious possible fixes:
  • (A) impose a lower upper bound on the frequency between proper checks
  • (B) offer a PrepareForNewLoop function (similar to CpuTimeLimit)

At the moment I prefer (B) but its does require cooperation from the user.
Maybe I should do both?

Or is the cause other than what I believe?

I also prefer (B). Maybe ResetForNewLoop?

#3 Updated by John Abbott over 1 year ago

  • Assignee set to John Abbott
  • % Done changed from 10 to 50

I have revised the impl -- it now works better.

Much of this code is quite similar to CpuTimeLimit.

The common part should be abstracted.

#4 Updated by John Abbott over 1 year ago

  • Target version changed from CoCoALib-0.99850 to CoCoALib-0.99880
  • % Done changed from 50 to 80

#5 Updated by John Abbott over 1 year ago

I am not so happy with the name myPrepareForLoop.
Is there a better name?

#6 Updated by John Abbott 2 months ago

Maybe just myReset? Or is that too vague? It is short, which I like.
So far we have been using myPrepareForNewLoop for over a year... well, maybe it has not been used much?

#7 Updated by John Abbott about 1 month ago

Or myRestart?

#8 Updated by Anna Maria Bigatti about 1 month ago

John Abbott wrote:

Or myRestart?

myReset is myFavourite ;-)

#9 Updated by John Abbott 23 days ago

  • % Done changed from 80 to 90

I have changed the name to myReset as Anna suggested. I have made the analogous change to CpuTimeOut, which is very similar to ProgressReporter. I have also added to myReset doc for ProgressReporter.

Maybe consider adding variability to ProgressReporter?

Will check in shortly.

#10 Updated by John Abbott 13 days ago

We should arrange to share code between ProgressReporter and CpuTimeout.
They both monitor the passage of time, and when enough time has passed take some action (print a message or throw an exception).

Also available in: Atom PDF