Re: The spinoza papers: towards a theory of progress reporting

On May 16, 6:47 am, spinoza1111 <spinoza1...@xxxxxxxxx> wrote:
I want the GUI of the spinoza system to not piss me off with the
usual
type of progress reporting one sees: the flashy, colorful, and
utterly
uninformative gizmos that go back and forth and round and round until
who knows when.

Therefore, the following C Sharp .Net code constitutes a theory of
progress reporting.

I claim that any fixed-count (limit available at run time before the
start) for loop can be monitored by considering it as the attempt to
accomplish a TASK, the accomplishment of which involves only the
processing of zero, one or more ENTITIES with an ENTITY COUNT. The
actual user (the person running the program) needs to see at what
rate
processing runs.

Each time through the loop, we are at a specific ENTITY NUMBER.

Progress and velocity can then be modeled visually by means of a
histogram such that:

histogramDimension/maxHistogramDimension = entityNumber/
entityCount

Solving for histogramDimension each time the "progress" handler runs:

histogramDimension = entityNumber/EntityCount *
maxHistogramDimension

The visual histogram can be anything from a widening, lengthening
"progress bar" to a bunny running down a field.

This can be done syncronously with the caveat that if it's done in
the
same thread (or even if not on a single processor "multiprocessing"
system) as actual work, it slows work down. In doing progress
reporting, one is trying to compensate for the expense in physical
time with some sort of magic show that speeds up the psychological
time experienced by the user.

Studies have shown users are more tolerant of relatively slow
processing as long as response is consistent. You might do better by
keeping that in mind rather than jumping thru hoops to make a better
magic show.

Think of it as the airline video you get in front of your seat even
back in steerage. Watching the wastes of Central Asia pass beneath
one
actually speeds up a Hong Kong to Paris flight because you can
actually see the Caspian come beneath you.

Of course, not all loops are fixed in number. For example, a program
such as Google's Picasa, which seems to want to search my hard drives
for images, is presumably walking a tree. A histogram model needs to
know the number of nodes in the tree at startup, and for large trees,
this might mean walking the tree to count before walking the tree to
do work. That's ridiculous. Here, you'd want to see a tree "grow"
even
though this would not show you how far you were to the end.

But even in cases of while and unknown-count for, it's user abuse to
show spinners and flashers that don't let the user know when the
process is done.

[]

Now, I claim that this model is sufficiently simple and general based
on Kant: Kant believed that all experience of necessity is time-
ordered on one dimension such that for any two points in the time as
experienced by one or more knowers, the "less than" or "greater than"
operators can be meaningfully used. Multiple concurrent processes can
be an array of histograms (and multiple users watching the process
can
lay bets on the winner if they be sporting gentlemen).

Thankfully for you, you are modeling the computer world while Kant was
trying to describe the real world. Unfortunately that agreed time-
orderliness doesn't exist in our Einsteinian universe.


When the entityCount is not known, an estimate can be made, perhaps
saving persistent state so that previous runs of the software give
the
following runs an idea of the count.

Boy a lot of thought just to present a progress bar.
Ed
.

Relevant Pages