Channels ▼

Clay Breshears

Dr. Dobb's Bloggers

Seeing the Light with Backtracking

December 22, 2011

Now, let's consider the three design schemes for parallel backtracking that were previously covered. Spawning a task for each recursive call that seeks to further explore the partial solution (Design 1) is easy to implement. A specific workload I used to test my solution code was a 24x15 grid that contained one 4-square, four 3-squares, 14 2-squares, 20 1-squares, four 0-squares, and 41 plain black squares. If none of the numbered squares had an adjacent black square reducing the available open adjacent white squares, this workload could potentially generate over 1.723E+21 (sextillion) tasks from the numbered squares alone. It's difficult to compute how many more tasks would be spawned from covering the remaining white squares. With such a mind-boggling task pool size, though, do we really want to know?

The final two designs can be done, as I showed in the NQueens() codes, with functions that spawn new tasks and versions that don't. A quick cut-and-paste and some added code lines can put the duplicated code into play. (You could keep the amount of code smaller by adding some conditional tests to decide whether or not to spawn a task at a recursive call, but, for me, the duplicated code is easier to understand.)

Each Akari puzzle is different and will have a different mix of numbered squares; plus, the number of legal bulb placement moves to be tested varies depending on the number in the square. The big question for the second (spawn all tasks at some level) and third (spawn tasks down to some level) design schemes is how to best arrange the numbered black squares to achieve the best performance. I wish I had some definitive advice to pass along, but the dynamic nature of the puzzles makes that almost impossible. Given enough sample inputs, you should be able to formulate some guidelines that will yield acceptable performance in the general situation.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video