Graeme wrote:I understand your point, but allow me to recap for the benefit of other readers. This is my view of why I see the 2 techniques as almost
opposite things:
The tail: (aka forcing chains)
- Code: Select all
. . . | . . . | . . .
. 12 . | . . . | . 13 .
. . . | . . . | . . .
-------------+---------------+-------------
. . . | . . . | . . .
. . . | . . . | . . .
. . . | . . . | . . .
-------------+---------------+-------------
. . . | . . . | . . .
. 23 . | . . . | . 345 .
. . . | . . . | . . .
r2c2=1 -> r2c8=3 -> r8c8<>3
r2c2=2 -> r8c2=3 -> r8c8<>3
Therefore, r8c8<>3
The tusk: (aka proof by contradiction or error chains)
- Code: Select all
. . . | . . . | . . .
. 12 . | . . . | . 13 .
. . . | . . . | . . .
-------------+---------------+-------------
. . . | . . . | . . .
. . . | . . . | . . .
. . . | . . . | . . .
-------------+---------------+-------------
. . . | . . . | . . .
. 23 . | . . . | . 345 .
. . . | . . . | . . .
r8c8=3 -> r2c8=1 -> r2c2=2
r8c8=3 -> r8c2=2 -> r2c2=1
This is a contradiction, therefore r8c8<>3
OR
r8c8=3 -> r2c8=1 -> r2c2<>1
r8c8=3 -> r8c2=2 -> r2c2<>2
Nothing left to go in r2c2, therefore r8c8<>3
The elephant: (labeled edges and a nice loop)
- Code: Select all
. . . | . . . | . . .
. 12-------------[1]--------------13 .
. | . | . . . | . | .
-----|-------+---------------+-------|-----
. | . | . . . | . | .
. [2] . | . . . | . [3] .
. | . | . . . | . | .
-----|-------+---------------+-------|-----
. | . | . . . | . | .
. 23-------------[3]-------------345 .
. . . | . . . | . . .
[r8c8]-3-[r8c2]-2-[r2c2]-1-[r2c8]-3-[r8c8]
The elephant is the underlying stucture that allows the one and only deduction. We can describe it as a forcing chain starting from r2c2, r2c8 or r8c8, OR as a proof by contradiction starting from r8c8=3.
If one thinks of these as a series of chronologically ordered implications, then there is a subjective difference between the various descriptions. But the temporal nature is an illusion.
If you more accurately think of the structure *as a whole*, existing at once -- like a real-world chain -- then forwards versus backwards is artificial.
As a *method* to *find* these deductions, proof by contradiction is perfectly valid but not new to sudoku. Some solver's (I'm not among them.) don't like it because they feel that it is too much like trial and error -- a number is placed in a cell (Why place the 3 not the 4?), tested to see if it works (What if it *does* work?) and backtrack if it doesn't. As a human solver, if I can see it, it counts, it is fair.
I think the problem arises when one tries to make software "solve by human methods". I can mentally place a number then follow along only so deeply, making mental eliminations equivalent to singles, maybe pairs, maybe intersections, etc. The limit is *my* personal limit. The software has no such personal limit and must be artificially capped -- otherwise it will be able to do an "error chain" elimination from the opening grid from nearly every cell. It's one thing to restrict it to finding naked pairs, swordfish, simple xy-type forcing chains of any length -- but unrestricted error chains (or unrestricted complex forcing chains as well) would be equivalent to brute force or recursive solving -- which of course, some humans *do* use to solve!
The discussion of human solving techniques always seems to assume that humans have only three levels of expertise -- novice, beginner and the rest. There seems to be no room for various levels of expert. Everyone seems to accept that Judit Polgar or Garry Kasparov can see many moves further in advance than a typical club player -- who would in fact trounce me though I've played for years. (In fact, the tendency in popular fiction is to imbue top chess players with ridiculous depth of search ability.) No one would or ever has claimed that what top players are actually doing is trial and error or guessing -- they are caclulating. But we don't seem to allow that one sudoku solver might be able to see past several virtual eliminations or recognize large burried patterns in order to make a deduction that appear to be magic to another.
Graeme wrote:tso wrote: They have nothing to do with Nishio. Nishio considers a single candidate.
Agree it's not much like Nishio, but it
does consider a single candidate like Nishio, and it removes that candidate from the test cell like Nishio, if the technique condition is met. Forcing Chains do neither. ... My opinion is that most human solvers only look at naked singles (and removing candidates affected by setting those values) when testing the implications of techniques like Nishio and Forcing Chains.
This is quite untrue for Nishio. Nishio considers the placement of ALL of one candidate, ignoring ALL of the other 72 digits. Nishio uses locked candidates as often as singles. These tactics are simply easy or obvious because Nishio is working on a sub-puzzle that has only 9 digits to place -- small enough to see all the way to the end of the game (like Judit Polgar). With forcing chains -- your milage may vary. More than once I only realized that I've included locked candidates or naked pairs as part of a forcing chain when I tried to write it down for posting.
Graeme wrote:In the simple examples above, one required just naked singles to allow it to work in reverse, while the other required naked pairs as well. ... Forcing Chains require you to remember, or note down implications of every test candidate, then compare every result before you can make any decision about what condidtions are met.
The level of complexity of the deduction remains unchanged regardless of which way the deductions are read. You're overlooking all the deductions you actually make because they are "obvious" -- what's obvious to you may not be to me. Error chains requires me to either note down, remember or note down exactly as much information -- unless I go ahead and erase candidates as I go along -- which would *strongly* risk getting into a postion from which I would be unable to backtrack -- how will I remember which candidates to put back in?
Graeme wrote:I would conceed that highly talented human solvers might use additional techniques in implication testing, but I really wonder how far they take it. Forcing Chains require you to remember, or note down implications of every test candidate, then compare every result before you can make any decision about what condidtions are met.
Error Chains are certainly much easier than that. I like your analogy with the elephant. IMHO, it's sometimes easier to grab it by the tail and call it a tail.
I disagree -- error chains is just as likely in a given situation to require much information to be recorded one way or another. It's purely subjective to state that error chains are easier. To demonstrate, here's your first example:
- Code: Select all
. . 56 | 35 . . | . . .
678 . 69 | . 2369 236| . . .
. . . | . . . | . . .
Error Chains:
A) If r2c1=6 -> (r1c3=5 AND r2c3=9 AND r2c5<>6 AND r2c6<>6)
B) If r1c3=5 (from A) -> r1c4=3 -> (r2c5<>3 AND r2c6<>3)
C) If r2c3=9 (from A) -> r2c5<>9
D) If r2c5<>6 (from A) AND r2c5<>3 (from B) AND r2c5<>9 (from C) -> r2c5=2 -> r2c6<>2.
E) But if r2c6<>6 (from A) AND r2c6<>3 (from B) AND r2c6<>2 (from C), the puzzle cannot be solved.
Therefore, r2c1<>6
Or by (much simpler) complex forcing chains:
r1c4=5 -> r1c3=6 -> r2c1<>6
r1c4=3 -> r2c5<>3 -> r2c356=[269] (naked triple) -> r2c6<>6
Therefore, r2c1<>6
I suppose I could just write in a 6 in r2c1 and solve from there in pencil, but I can *always* do that!