<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to not solve a Sudoku</title>
	<atom:link href="http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/feed/" rel="self" type="application/rss+xml" />
	<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/</link>
	<description>thinking outside the { }</description>
	<lastBuildDate>Thu, 12 Aug 2010 18:37:05 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: devgrind &#187; Learning by Testing</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-32</link>
		<dc:creator>devgrind &#187; Learning by Testing</dc:creator>
		<pubDate>Tue, 22 May 2007 12:57:34 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-32</guid>
		<description>[...] Maybe I&#8217;m a bit hypersensitive here, but I have some reservations when it gets to using tests to find out how things (could or should) work. I&#8217;d think it would it be better to just look it up in a reference and write the test [...]</description>
		<content:encoded><![CDATA[<p>[...] Maybe I&#8217;m a bit hypersensitive here, but I have some reservations when it gets to using tests to find out how things (could or should) work. I&#8217;d think it would it be better to just look it up in a reference and write the test [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: devgrind &#187; Between Heaven and Earth</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-26</link>
		<dc:creator>devgrind &#187; Between Heaven and Earth</dc:creator>
		<pubDate>Fri, 04 May 2007 12:23:00 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-26</guid>
		<description>[...] Today I stumbled upon another source of developer wisdom, Des Traynor&#8217;s Programming Theorems. One of the theorems rings especially true for me after the recent insights into developing a Sudoku solver the TDD way: [...]</description>
		<content:encoded><![CDATA[<p>[...] Today I stumbled upon another source of developer wisdom, Des Traynor&#8217;s Programming Theorems. One of the theorems rings especially true for me after the recent insights into developing a Sudoku solver the TDD way: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Reese</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-24</link>
		<dc:creator>John Reese</dc:creator>
		<pubDate>Thu, 26 Apr 2007 17:22:49 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-24</guid>
		<description>@Mernet:  I believe the distinction he is making is not so much that it is or isn&#039;t a backtracking algorithm, but rather that rather than having to explicitly deal with backtracking by reverting the data structure, the recursive nature of operation means that any failed path will automatically return up the chain to where the individual data structures are still in previous condition.</description>
		<content:encoded><![CDATA[<p>@Mernet:  I believe the distinction he is making is not so much that it is or isn&#8217;t a backtracking algorithm, but rather that rather than having to explicitly deal with backtracking by reverting the data structure, the recursive nature of operation means that any failed path will automatically return up the chain to where the individual data structures are still in previous condition.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Memet</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-22</link>
		<dc:creator>Memet</dc:creator>
		<pubDate>Thu, 26 Apr 2007 11:31:26 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-22</guid>
		<description>@Arne: check. I was just puzzled by his claim that it wasn&#039;t...

&quot;The alternative is to keep track of each change to values and undo the change when we hit a dead end. This is known as backtracking search. It makes sense when each step is a single change, but is usually too complicated to bother with when each change can lead to many other changes via constraint propagation.&quot;

 Which made me question (along with the previous paragraph I quoted about the search algorithm) if he was not having deep branching. i.e. that the choice was a single square being searched on.

 I guess as far as he is concerned, it is only called backtracking in the case that you hold a list of the changes and have a master state, rather than having a list of copy states. I would have still called the DFS search backtracking, but I can live with his terminology so long as I&#039;m clear.

 Anyways, thanks.</description>
		<content:encoded><![CDATA[<p>@Arne: check. I was just puzzled by his claim that it wasn&#8217;t&#8230;</p>
<p>&#8220;The alternative is to keep track of each change to values and undo the change when we hit a dead end. This is known as backtracking search. It makes sense when each step is a single change, but is usually too complicated to bother with when each change can lead to many other changes via constraint propagation.&#8221;</p>
<p> Which made me question (along with the previous paragraph I quoted about the search algorithm) if he was not having deep branching. i.e. that the choice was a single square being searched on.</p>
<p> I guess as far as he is concerned, it is only called backtracking in the case that you hold a list of the changes and have a master state, rather than having a list of copy states. I would have still called the DFS search backtracking, but I can live with his terminology so long as I&#8217;m clear.</p>
<p> Anyways, thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arne</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-21</link>
		<dc:creator>Arne</dc:creator>
		<pubDate>Wed, 25 Apr 2007 21:31:22 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-21</guid>
		<description>Memet, I&#039;m not sure if I get you right: after eliminating impossible alternatives through constraint propagation, Norvig uses a DFS for searching the remaining problem space. So yes, the second part is &quot;just a backtracking algorithm&quot;.</description>
		<content:encoded><![CDATA[<p>Memet, I&#8217;m not sure if I get you right: after eliminating impossible alternatives through constraint propagation, Norvig uses a DFS for searching the remaining problem space. So yes, the second part is &#8220;just a backtracking algorithm&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Memet</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-20</link>
		<dc:creator>Memet</dc:creator>
		<pubDate>Wed, 25 Apr 2007 20:49:14 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-20</guid>
		<description>I have a question/issue about this algorithm.

 A while ago I wrote myself a sudoku solver in scheme to explore the capabilities of amb (which is quite an elegant closure based implementation of backtracking). But there&#039;s an assumption he (Norvig) makes that I don&#039;t know is trivial. 
 Why should substituting only one square guarantee a solution? I refer to:
&quot;Simple: first make sure we haven&#039;t already found a solution or a contradiction, and if not choose one unfilled square and consider all its possible values. One at a time, try assigning the square each value, and searching from the resulting position.&quot;

 Maybe I&#039;m not understanding what he means but it&#039;s either one of two things:
a) a sudoku puzzle can be solved with only one guess cell. (if so: why?)
b) the DFS search algo he is proposing is just a backtracking algorithm since DFS will eventually &#039;pop the stack&#039; which is essentially what backtracking is all about. It&#039;s just an implementation detail.

Maybe I misread or am completely misunderstanding, anyone care to clarify?</description>
		<content:encoded><![CDATA[<p>I have a question/issue about this algorithm.</p>
<p> A while ago I wrote myself a sudoku solver in scheme to explore the capabilities of amb (which is quite an elegant closure based implementation of backtracking). But there&#8217;s an assumption he (Norvig) makes that I don&#8217;t know is trivial.<br />
 Why should substituting only one square guarantee a solution? I refer to:<br />
&#8220;Simple: first make sure we haven&#8217;t already found a solution or a contradiction, and if not choose one unfilled square and consider all its possible values. One at a time, try assigning the square each value, and searching from the resulting position.&#8221;</p>
<p> Maybe I&#8217;m not understanding what he means but it&#8217;s either one of two things:<br />
a) a sudoku puzzle can be solved with only one guess cell. (if so: why?)<br />
b) the DFS search algo he is proposing is just a backtracking algorithm since DFS will eventually &#8216;pop the stack&#8217; which is essentially what backtracking is all about. It&#8217;s just an implementation detail.</p>
<p>Maybe I misread or am completely misunderstanding, anyone care to clarify?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arne</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-19</link>
		<dc:creator>Arne</dc:creator>
		<pubDate>Wed, 25 Apr 2007 20:43:09 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-19</guid>
		<description>:)</description>
		<content:encoded><![CDATA[<p> <img src='http://devgrind.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ravi Mohan</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-18</link>
		<dc:creator>Ravi Mohan</dc:creator>
		<pubDate>Wed, 25 Apr 2007 20:27:31 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-18</guid>
		<description>&quot;And it supports my impression that in these days too many people in the development world focus on the methodological aspects of software development and underestimate the importance of fundamentals such as algorithm design.&quot;

Thank YOU!!!! At least one person understood what I was trying to convey :-)

Ravi</description>
		<content:encoded><![CDATA[<p>&#8220;And it supports my impression that in these days too many people in the development world focus on the methodological aspects of software development and underestimate the importance of fundamentals such as algorithm design.&#8221;</p>
<p>Thank YOU!!!! At least one person understood what I was trying to convey <img src='http://devgrind.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>Ravi</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arne</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-17</link>
		<dc:creator>Arne</dc:creator>
		<pubDate>Wed, 25 Apr 2007 20:22:47 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-17</guid>
		<description>Thanks, Vlad :)</description>
		<content:encoded><![CDATA[<p>Thanks, Vlad <img src='http://devgrind.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arne</title>
		<link>http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/comment-page-1/#comment-16</link>
		<dc:creator>Arne</dc:creator>
		<pubDate>Wed, 25 Apr 2007 20:18:07 +0000</pubDate>
		<guid isPermaLink="false">http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/#comment-16</guid>
		<description>Okay, this is basically what you get if you remove the constraint propagation and rely on a depth-first search through problem space only. Easy to grasp &amp; to implement, but - as you say - prone to complexity issues. Nice addition, though.</description>
		<content:encoded><![CDATA[<p>Okay, this is basically what you get if you remove the constraint propagation and rely on a depth-first search through problem space only. Easy to grasp &#038; to implement, but &#8211; as you say &#8211; prone to complexity issues. Nice addition, though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
