[eclipse-clp-users] How can bb_min fail after finding a solution?

From: Matthew Skala <mskala_at_...203...>
Date: Fri, 15 Feb 2013 10:29:22 -0600 (CST)
I'm getting output like this from bb_min/3:

   Found a solution with cost 6
   Found a solution with cost 5
   Found a solution with cost 4
   Found no solution with cost 0.0 .. 3.0

   No (0.06s cpu)

How can this be?  If the labelling routine ever succeeds, then shouldn't
bb_min also succeed?

My labelling routine is a complicated one involving Cardinal and a bunch
of hand-implemented heuristics.  I'm trying now to come up with a minimal
example to demonstrate the above behaviour; but if there exists a simple
and general explanation of the circumstances under which bb_min is able to
return failure after labelling has succeeded, that would help.  I suspect
that Cardinal may be misbehaving in some way, along the lines of leaving
suspended goals; but I don't think suspended goals are exactly the problem
because I have also seen bb_min succeed with labelling routines that left
suspended goals.

Trying to step through it in the debugger doesn't seem to work - after it
has found a solution, the "step" command in the debugger never returns to
a prompt.  I don't know if it is merely slowed down by a factor of many
thousands, or not debuggable at all, or if "step" is the wrong way to do
it, but in any case I haven't been able to get a debugging session to the
point where bb_min is failing.

I might be able to work around the issue by making my labelling routine
save the best solution it finds - then I could ignore bb_min's success or
failure - but in that case, I'll be close to having reimplemented bb_min
for myself.
-- 
Matthew Skala
Postdoctoral Fellow, University of Manitoba
mskala@...287...
Received on Fri Feb 15 2013 - 16:51:09 CET

This archive was generated by hypermail 2.2.0 : Mon Jul 09 2018 - 02:05:30 CEST