Calculating remaining time for set of functions
tooprock
I have written a toolkit for analysis of a large scientific data. For this purpose, I use several functions with too many loops and complex calculations. It would be great to have a panel which shows user the remaining time for a complete analysis (some kind of progress screen which appers on Microsoft Windows when we install something). I have some ideas but couldn't bring them together. Some hints? Thank you.
Best,
Emre
You can also open the Progress Demo experiment which you can get to from the File->Example Experiments->Feature Demos 2 menu item.
April 3, 2013 at 05:56 am - Permalink
April 4, 2013 at 02:21 am - Permalink
Some time ago, I wrote a package to display a progress window. I will upload it as a project. Unfortunately, it is probably not usable in its present form, but you may get some ideas from it. I will give it some attention in the near future, if I get the chance.
April 4, 2013 at 05:28 am - Permalink
Unless you provide more information it's difficult to provide you with further help.
If you're looking for a way to calculate the remaining time, you'll probably need to use a timer to determine the length of time a certain percentage of the task takes and then extrapolate from there. For timing you can use the StartMSTimer/StopMSTimer operations. But as I'm sure you're seen before, progress windows that show you the time remaining are usually pretty unreliable, so you might want to consider whether it is worth your time to try to display the actual remaining time instead of just the % complete.
April 4, 2013 at 06:09 am - Permalink
John Weeks
WaveMetrics, Inc.
support@wavemetrics.com
April 4, 2013 at 08:57 am - Permalink
You may be reading too much into tooprock's request. I didn't think the windows installer even attempted to tell you how much time is left. If I'm wrong it's because it's so innacurate I've tuned it out, but it's still nice to have some sign the computer hasn't frozen. In a scientific calculation with nested for loops you often get much more linear time vs. iterations behavior. There's no waiting for a registry lookup or interrupting and restarting random windows services. It can be very handy to have a rough visual estimate as to whether I should sit and wait for the calculation to finish, go find something else to do, or cut it off and run it over night.
I use the "poor man's progress bar" in a number of analysis packages: In Igorese it looks like:
for (index0 = 0; index0 < numsteps0; index0 ++ 1)
if (mod(index0,100)) // optional only update progress every 100 iterations.
// print (index0 / numsteps0 * 100), " percent complete" // uncomment for a percentage estimate
printf "." // ASCII art progress bar. comment out if using above line.
endif
[more nested loops go here]
// Don't bother embedding any further down...
// If you haven't seen the first update yet you're in for a long wait!
endfor
Replace index0 and numsteps0 with the variables you use in the outer loop. You need the mod check if the outermost loop is a large number of relatively fast iterations (printing and other display updates can be very slow relative to number crunching) and if it's a really small number of iterations, move the progress code into the next loop (slightly more complicated percent complete calculation based on two loop variables now).
I thought there was a graphical progress bar XOP, but perhaps I was just thinking of jtigor's "progress bar" package.
April 5, 2013 at 09:59 am - Permalink
This is why when you install or update programs, often the "Time Remaining" will count down to zero seconds remaining and then sit there for many minutes. It's unreliable, but a fun way to make users happy.
Perhaps a better option is to provide a progress window that shows the percentage completed along with a counter that displays the seconds/minutes since the operation started. You could then use this data to continually update an ETA, but it may not always be accurate, especially if the data being crunched is irregular.
April 5, 2013 at 10:38 am - Permalink
startMsTimer and stopMsTimer. What else I have done is calculating the remaining job as pencent since I know how many files I analyse. However, after I read your comments I decided to make a great change on working principle of the toolkit. This is how it looks like after all changes.Variable refnumTimer, timeElapsed, timeasprogress
// Read strings from list and set data folder accordingly
Variable numDataFolders = ItemsInList(DataFolderList)
Variable i
NVAR perc = root:perc
Variable progress = 0
ControlUpdate/W=toolKIT/A
for(i=0; i<numDataFolders; i +=1)
refnumTimer = startMSTimer
String nameCurDF = "root:RDDataFolder:" + StringFromList(i, DataFolderList)
SetDataFolder nameCurDF
AnalyseWIBSFiles() // Main function which performs analysis
timeElapsed = stopMSTimer(refnumTimer)
timeasprogress = timeElapsed/1000000 // elapsed time as seconds
//print "Last file took " + num2str(timeasprogress) + " seconds" // We can see how long it takes to analyse a file
progress += 1
perc = (progress / numDataFolders) * 100
ControlUpdate/W=toolKIT progress
// change progress color to green.
ValDisplay progress win=toolKIT, highColor= (26112,0,10240)
endfor
April 11, 2013 at 06:30 am - Permalink
Also, didnt xkcd do a comic on this? yeah, there it is http://xkcd.com/612/
April 11, 2013 at 11:49 am - Permalink
April 11, 2013 at 02:26 pm - Permalink