The New Sudoku Players' Forum

[SpAce]

David and Phil provide clarity here.

How does Phil provide clarity if his rule set is both incomplete and redundant, as I pointed out? Or was I wrong? Just asking Edit: I think I was indeed wrong

I am now a solid proponent of the Eureka notation for chains. David's writings have convinced me.

I don't know what David has written about them, but at least I didn't need any convincing. I only know three sudoku notations: generic implication chains (like eleven's), Nice Loop notation, and Eureka. I learned them in that order, because the first one is self-explanatory and the Nice Loop notation is pushed by every strategy site. Eureka I learned here. Of those three the Nice Loop notation is the worst in every way, so that leaves two practical choices. Of them the implication chains are the simplest to write and understand without any prior knowledge, which is a major benefit. On the other hand, Eureka is the most expressive one. When properly written it's often easy to follow Eureka chains without even seeing the grid. Most importantly, it's the de facto standard here, and I like standards because they help communication. So my vote is for Eureka, but I don't mind seeing implication chains either. I'd be quite happy to see the Nice Loop notation die out, though. Too bad Hodoku etc keep using it.

Phil's solver shows that ALS-XZ and ALS-XY moves can be very nicely written as chains using Eureka.

Of course they can. They are chains, and to me it's the simplest way to see and use them. No need to understand their RCCs and elimination rules as long as you understand how generic chains work. Otherwise I still wouldn't even be able to use them, as I have no interest in memorizing every single pattern there is, as long as it's covered by some generic rule. Seen as chains ALS patterns are pretty straightforward to me, while as ALS patterns they're not intuitive at all.

[pjb]

SpAce wrote:

What about Discontinuous Type 2 (the placing loop)? I think it's missing but you could add it as a special case of 1.

I don't see the "type 2" as being any different to the other discontinuous nice loops. Let's say a chain starts with X= and ends with -X. In the "type 2" the ending and starting X's not only see each other but are the only 2 in the unit ( allowing the x=x= configuration). Then eliminating the ending X causes the starting X to be true.
Phil

[eleven]

It is not clear to me that the reverse is always possible.

The reversibility of chains just relies on the the simple logic fact, that A=>B is equivalent to (not B)=>(not A). A implies B means "if A then B". The reverse is "if not B then not A". "If you are a good solver, you can solve hard puzzles", is equivalent to "if you cannot solve hard puzzles, you are not a good solver".

How about Kraken Units? How about Kraken Fish with more than one fin? Are they not unidirectional? If such can be viewed as bidirectional, please correct this view by providing how such reverse routes would work. With these moves, the explicit branching is in play.

Kraken Units are 3-(or more) way conclusions, different to classic 2-way AIC's, where they were not possible at all. Now we write Krakens like the good old more-way forcing chains, but use AIC notation instead of '=>' signs.
And fish are patterns. This has nothing to do with AIC, apart from the problems AIC converts have, how to integrate them.

[SpAce]

I don't see the "type 2" as being any different to the other discontinuous nice loops. Let's say a chain starts with X= and ends with -X. In the "type 2" the ending and starting X's not only see each other but are the only 2 in the unit ( allowing the x=x= configuration). Then eliminating the ending X causes the starting X to be true.

Okay, I accept that it's implicitly covered by your case 2, but that in turn is covered by 1.a. That leads to my other point: why do you have case 2 at all if you're aiming for a minimum rule set (as I assumed)? Also, you're only talking about cases when the start and end digits are the same, which does not cover all (and in fact probably the most common) AICs or discontinuous loops. That is a more serious problem, I think.

Edit: I think I must stand corrected on the latter issues too (even if I do the correcting myself). I guess your case 2 actually covers the different digit scenario, so it may not be redundant after all. The only problem remaining is that you must then travel the chain backwards to get the other possible elimination (of the other digit if it exists in the original start cell). That's more like seeing it as two discontinuous loops instead of one AIC operation. Not that it matters unless you're counting steps.

[SpAce]

It is not clear to me that the reverse is always possible.

The reversibility of chains just relies on the the simple logic fact, that A=>B is equivalent to (not B)=>(not A). A implies B means "if A then B". The reverse is "if not B then A". "If you are a good solver, you can solve hard puzzles", is equivalent to "if you cannot solve hard puzzles, you are not a good solver".

Indeed.

PS. I guess you meant "if not B then not A". (I hate to point out typos; I just happen to notice them easily and assume people would like to correct them like I would. If it annoys someone, I can stop.)

[eleven]

I guess you meant "if not B then not A".

Of course, thanks.

[ghfick]

I guess I am applying a boundary that is to some extent self-imposed. It appears to be difficult to determine just where one places the boundary between assumptive and non-assumptive. Some solvers have no interest in such boundaries. I do enjoy when a puzzle has more than one quite interesting solution path. I am inclined to avoid assumptive methods until I believe there is no non-assumptive steps left.
For example, I will look for Junior Exocets, SK Loops and the simpler MSLSs before looking for chains that [appear to ] require memory of past steps or [appear to] require branching.
David P Bird has prepared a number of documents that offer careful, thorough and well argued positions. His JE Compendium is quite amazing. I can claim to understand a portion of it and it is still an area of active study for me.
Phil's solver and accompanying documentation is superb for learning as well. I might give Bernhard Hobiger's HoDoKu my highest rating except that this solver is not as up to date. Bernhard's last update was back in 2012. I continue to enjoy and appreciate Andrew Stuart's solver and documentation. StrmCkr is developing a very impressive solver that is currently MS Windows only though.
Gordon

[StrmCkr]

StrmCkr is developing a very impressive solver that is currently MS Windows only though.

thanks again:
its a free pascal compiler project coded in old school Turbo pascal with some updates
it is set to run in Command prompt and uses some 64 bit code on a few techniques.

i should have some more updates for it by the new year i have expanded a lot of stuff greatly over the holidays