Rate counter: Difference between revisions

Content added Content deleted
(→‎{{header|Fortran}}: A rethink being prompted.)
Line 565: Line 565:


So, in <lang Fortran> DO I = FIRST,LAST
So, in <lang Fortran> DO I = FIRST,LAST
IF (PROGRESSNOTE(I - FIRST,LAST - FIRST)) WRITE (6,*) "Reached ",I,", towards ",LAST
IF (PROGRESSNOTE((I - FIRST)/(LAST - FIRST + 1.0))) WRITE (6,*) "Reached ",I,", towards ",LAST
...much computation...
...much computation...
END DO</lang>
END DO</lang>
Function PROGRESSNOTE is invoked at the start of each iteration, with its first parameter stating how many steps have been completed (initially, none: this restarts its timers) and the second indicates how many are to be made. The function notes whether sufficient clock time has elapsed since its previous report (more than six seconds, for example) and if so, returns ''true'' after starting an output line with a standard report giving an estimated time to run and an estimated time (and date, if not the current day) of finishing. This line is not terminated; the invoking routine appends its own progress message, tailored to the nature of the task it is working through. For instance,
Function PROGRESSNOTE is invoked at the start of each iteration, with its parameter stating how much progress has been made on a scale of zero to one, with a "zero progress" restarting its timers. The function notes whether sufficient clock time has elapsed since its previous report (more than six seconds, for example) and if so, returns ''true'' after starting an output line with a standard report giving an estimated time to run and an estimated time (and date, if not the current day) of finishing. This line is not terminated; the invoking routine appends its own progress message, tailored to the nature of the task it is working through. For instance,
<pre>
<pre>
Standard progress report|Tailored message.
Standard progress report|Tailored message.
Line 576: Line 576:
ETF + 6·1hrs!@Monday 17/ 7/2017 5:21:23·397am. 0% Dumping Friday 16/ 5/1749.
ETF + 6·1hrs!@Monday 17/ 7/2017 5:21:23·397am. 0% Dumping Friday 16/ 5/1749.
</pre>
</pre>
Thus, the user waiting at the computer screen can monitor the rate of progress and know to go for a walk, or not.
Thus, the human waiting at the computer screen can monitor the rate of progress and know to go for a walk, or not.


Incidentally, on windows systems at least, frequent invocations of the date and time routine can cause execution to run ''much'' slower, or worse. A loop waiting for the system's DATE_AND_TIME result to attain a specified value will instead cause a crash.
Incidentally, on windows systems at least, frequent invocations of the date and time routine can cause execution to run ''much'' slower, or worse. A loop waiting for the system's DATE_AND_TIME result to attain a specified value will instead cause a crash.

For another approach, imagine a long-running program, WORKER, that writes various remarks to standard output as it goes, and consider another, TIMESTAMP, that copies from standard input to standard output, prefixing each line with a date and time stamp, perhaps invoked via something like <code>WORKER | TIMESTAMP >Log.txt</code> - the vertical bar an amusing choice to symbolise a horizontal "pipe". When everything finishes, the log file can be analysed to determine the rate of progress. But alas, in the windows world, the stages of a "pipeline" are performed serially, not simultaneously - the vertical bar symbolising this separation. All output from WORKER will be saved in a temporary disc file then when WORKER finishes that file will be fed as input to TIMESTAMP, thereby producing data only on the rate of file input/output.


=={{header|Go}}==
=={{header|Go}}==