On 6/9/06, Luis Quesada <[EMAIL PROTECTED]> wrote:
Dear Torsten,
> I really like this approximation you propose. Of course, the 'progress
> bar' may quick go to, say, 90% and then stay there forever and
> eventually fall back again. Still, that's at least some feedback..
Indeed the progress reported does not evolve monotonically. It is also
true that you may get stuck at 90%. However, this might suggest that it
is time to abort your search and have a look at the remaining 10%. Maybe
the reason why it is so hard to determine them is a bug in the input
data...
In fact, I have found this approximation useful when dealing with tough
CSP where finding one solution may take hours.
The initial request for a progress bar got me thinking along these
same lines of developing a non-linear progress bar based on the size
of the remaining domains. I realized that you could also use it in a
debugging/optimization mode where you have multiple progress bars,
each one observing some subset of your variables (possibly only one)
so that you could get an idea of which variable domains were being
narrowed quickly and which ones were not in the hopes of discovering
some aspect of the problem that needed further constraining/optimizing
(e.g. making explicit some constraints that may have otherwise
remained implicit).
Of course, like Himanshu mentioned, this doesn't generalize well for
all problems. Imagine a problem were you start out with some
variables with small domains but in the course of solving the problem
you dynamically generate other variables. Does the progress bar then
have to shrink to accomodate the new 100% total? Imagine the worst
case of using FD.decl. Your progress bar could potential be jumping
all over the place during the run of a particularly complicated csp.
Rob
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
