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_at_cs.umanitoba.caReceived on Fri Feb 15 2013 - 16:51:09 CET
This archive was generated by hypermail 2.2.0 : Sat Feb 16 2013 - 06:14:30 CET