- Mail actions: [ respond to this message ] [ mail a new topic ]
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Joachim Schimpf (Independent Contractor) <"Joachim>

Date: Sun, 02 Mar 2008 20:20:01 +0000

Date: Sun, 02 Mar 2008 20:20:01 +0000

Kish Shen wrote: > kot23 wrote: ... >> The output I have is like this: >> >> : backtracks : 0 >> Found a solution with cost 335 >> : backtracks : 901 >> Found a solution with cost 285 >> : backtracks : 904 >> Found a solution with cost 270 >> : backtracks : 915 >> Found a solution with cost 255 >> Found no solution with cost 240.0 .. 240.0 >> >> So, my question is, what is the real number of backtracks, for finding >> the last solution in the case above? Is it "915" backtracks or the sum of >> each intermediate solution, ie: 0+901+904+914=2719 backtracks? >> >> Thanks, >> Christoforidis Nikos >> >> > As stated in the documentation, the backtracks reported is the number of > backtracking steps used in the search routine, i.e. 915 is the total > number of backtracks performed by the search to find the last (optimal) > solution. There is a slight pitfall here: what Kish says is only true as long as you use the strategy 'continue' in bb_min (which is the default). If you set the strategy option to 'restart' or 'dichotomic', then the search predicate will be re-started after every new minimum found, therefore it will restart with a backtrack counter of 0 every time, and you will have to add the counts in order to get the total. -- JoachimReceived on Sun Mar 02 2008 - 20:20:20 CET

*
This archive was generated by hypermail 2.3.0
: Mon Jun 24 2019 - 18:14:57 CEST
*