0
$\begingroup$

Would it be possible to build a progress bar that estimates progress using entropy?

Consider a web browser that is downloading a large file (for instance), which displays a progress bar indicating the amount of progress in the download. Let $X$ denote the value of the complete file; it is not known until the download completes. At time $t$, we have downloaded part of the time, so let $Y_t$ denote the information/data received by time $t$. Initially, at $t=0$, we do not know $X$ (there is some prior distribution on $X$). The observed data narrows down the set of possible values of $X$. The more we observe, the less uncertainty there is about $X$; once we've finished downloading the entire thing, the value of $X$ is known and there is no more uncertainty.

Could we use the entropy $H(X | Y_t)$, or something like that, to estimate progress so far and build the progress bar? Would this work theoretically? Would it work in practice? Would it be useful?

Would something similar work for software installation or other uses of progress bars?

$\endgroup$
6
  • $\begingroup$ $X^n$ represents the content of those memory cells, which clearly is random to us. $X_i^n$ is the $i:th$ memory cell of the memory block we are reserving. If we have no uncertainty in what we want to write to our reserved block, then we can break transmission and thus progress is complete. $\endgroup$ May 15, 2015 at 7:10
  • $\begingroup$ I thought it was a rather well-posed model, feel free to point out what makes it faulty/confusing. $\endgroup$ May 15, 2015 at 7:13
  • $\begingroup$ Actually, I suspect this definition would be 100% equivalent to the 'normal' definition of progress... $\endgroup$ May 15, 2015 at 7:20
  • $\begingroup$ If you KNEW what the web page wanted to transmit before hand, obviously it wouldn't have any uncertainty, but in that case, then why are you transmitting it at all? $\endgroup$ May 15, 2015 at 7:22
  • $\begingroup$ OK, I've tried editing the question based upon my understanding of what you are saying, going by your comments and your example of downloading a web page. I've tried to turn this into a more well-defined, answerable question. Does this edit accurately reflect your intent? $\endgroup$
    – D.W.
    May 15, 2015 at 7:30

1 Answer 1

2
$\begingroup$

For downloading a file, yes, this would work.

For a file download, there is a much simpler method: let $n$ be the total number of bytes of the file to be downloaded, and $k$ the number of bytes we have downloaded so far; then $k/n$ is a good estimate of our progress (the fraction of the file we've downloaded so far).

This turns out to be equivalent to your entropy-based notion, if we assume that the file contents are iid bits (i.e., uniform distribution over all possible files of that length).

So why count bytes instead of use entropy? Well, if they're equivalent, they are just two different ways of describing the same thing. However, it's much simpler to just count bytes. Also, counting bytes has the advantage of being something that can be implemented. Calculating the entropy of the file requires some way to measure entropy, which requires a formula -- and in this case, the formula is to count bytes, so we reduce back to the standard metric.


A progress bar for a software update isn't nearly as easy, because it often involves multiple different kinds of operations, which progress at different speeds. Also, there is often no uncertainty: the installer knows exactly what files it is writing. The purpose of the installation is to have a side effect. We want to measure how long it will take until that side effect is completed. It's not clear that this will fit into the entropy framework, because an entropy framework doesn't take into account how long it will take for those side effects to complete. For instance, how long will it take to write one 100MB file and 1000 1KB files? Hard to say, but I can tell you it's not simply proportional to the number of bits in the files, or the number of bits of entropy -- short files may require a seek, so the time to write a file is not proportional to the length of the file.

$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.