The New Sudoku Players' Forum

[ArkieTech]

Code: Select all

 *-----------*
 |.3.|...|2.6|
 |4..|3..|9..|
 |7..|.2.|.43|
 |---+---+---|
 |1..|.76|...|
 |..3|1.5|4..|
 |...|94.|..1|
 |---+---+---|
 |51.|.3.|..7|
 |..8|..2|..4|
 |2.7|...|.5.|
 *-----------*


Play/Print this puzzle online

[SpAce]

No answers? I guess it implies the obvious solution (X-Chain of length 6) is a bit too easy. I'm speaking only for myself, but I would propose that non-grouped X-Chains (of any length) would be added to the list of "too simple solutions" for these puzzles. I think they're much easier to spot than basic (non-chainable) fishes (or XY-Wings, XYZ-Wings, or W-Wings) which are already on that list. Grouped X-Chains are fine, but non-grouped ones seem too trivial in almost all cases. Would anyone strongly disagree?

Anyway, to get something out of it, I tried a technique I'd never used before:

Code: Select all

.-------------------.------------------.-------------------.
|  8-9a  3     15-9 | 458  19b   14789 | 2    178    6     |
|  4     2568  1256 | 3    16    178   | 9    178    58    |
|  7     5689  1569 | 568  2     189   | 158  4      3     |
:-------------------+------------------+-------------------:
|  1     48-9  4-9  | 2    7     6     | 58   3     +9A-58 |
| +9A-6  7     3    | 1    8     5     | 4    6-9a   2     |
|  68    25    25   | 9    4     3     | 7    68     1     |
:-------------------+------------------+-------------------:
|  5     1     469c | 468  3     489C  | 68   2      7     |
|  3     6-9a  8    | 7    5     2     | 16  +9A-1   4     |
|  2     469   7    | 468  169B  1489  | 3    5      8-9a  |
'-------------------'------------------'-------------------'


Multi-Colors Wrap (9): parity 'a' in cluster (aA) sees both parities of cluster (bB), hence 'a' must be false and 'A' true.
=> +9 r4c9,r5c1,r8c8; stte

Note also:

Multi-Colors Trap (9): B and C see each other -> b or c must be true => -9 r1c3
Simple Colors Trap (9): r4c2 sees both parities of cluster (aA) => -9 r4c2 (already included in the MC Wrap).

Edit 1: added the traps
Edit 2: changed the tags

[SteveG48]

No answers? I guess it implies the obvious solution (X-Chain of length 6) is a bit too easy. I'm speaking only for myself, but I would propose that non-grouped X-Chains (of any length) would be added to the list of "too simple solutions" for these puzzles. I think they're much easier to spot than basic (non-chainable) fishes (or XY-Wings, XYZ-Wings, or W-Wings) which are already on that list. Grouped X-Chains are fine, but non-grouped ones seem too trivial in almost all cases. Would anyone strongly disagree?

It sounds like a solution in search of a problem. I didn't even know that we had a list of "too simple solutions".

Personally, I don't care what solutions folks want to post. If the poster is happy with it, then he should go for it. If an experienced solver posts an obvious solution just to get it out of the way, that's fine too.

[ArkieTech]

Xchains will join the "easy list". Any suggestions on how to attract new players?

[SpAce]

It sounds like a solution in search of a problem. I didn't even know that we had a list of "too simple solutions".

Personally, I don't care what solutions folks want to post. If the poster is happy with it, then he should go for it. If an experienced solver posts an obvious solution just to get it out of the way, that's fine too.

Looks like you misunderstood my point. Of course anyone is free to post any applicable solution, and I would never suggest anything else. The simplest possible makes obviously the most sense too, so no one should be blamed for posting that!! My suggestion was about the puzzles themselves and with what techniques they're stte-solvable. As Leren points out here:

Also, Dan usually left out some of the easier moves like Swordfish, Kites, ER's and XY wings. We'd generally feel a bit let down if a puzzle solved with just one of these, but over the years a few snuck through the net.

I haven't seen any of those simple techniques (or the others I mentioned) snuck through the net in my time here, so Dan's filters seem to work well. I just happen to think that non-grouped X-Chains could be added to that list as well -- but only if others agree that it's a good idea. Personally I'm feeling a bit let down if a puzzle solves with just X-Chains, that's all. Also, for some reason puzzles solvable with X-Chains seem less likely to have meaningful variance, so other solutions often just include the same logic in a more complicated package. (I have no idea if that's true or just my biased memories.)

If my opinion is in the minority, that's fine. I'm just curious if I'm the only one who thinks X-Chains are too trivial. Pure X-Chain puzzles are pretty rare here anyway so there's absolutely no problem in general. I'm grateful for any puzzles Dan feels like posting. I was just curious why no one felt like posting a solution for this one -- and wondered if the reason was the same as mine.

[SpAce]

Xchains will join the "easy list".

Thanks! Hope everyone else agrees with it.

Any suggestions on how to attract new players?

I keep my promise and take a vacation?

[rjamil]

Actually, I always see myself as one of the new players in Sudoku Puzzles thread.

Everytime, when I added/modify my Sudoku solver program, need some specific properties containing Sudoku puzzle in order to test my solver program compliance. I have started participating Puzzle thread and try to compare only those puzzles that are solvable by my solver with added OTP/2TP move feature by simply shuffling moves order or by completely disabling some moves.

Basically, being programmer, do not want to become Sudoku professional player. And consider other programmers (like Andrew Stuart) policy, which is totally based on moves that are not only presented in exemplar form only but to program for speed searching too.

I think, there are few participants that participate in puzzle solving thread only to test his/her program skills, like myself, and they do not want to translate each and every move into some really professional way that uses expert in p&p. This thread puzzles are definitely not replacement of puzzles that are published in newspapers, magazines, etc.

Hope, I explained my pov regarding newcommers vs basic/advance move concept of this thread new participants.

R. Jamil

[SpAce]

Hi rjamil,

Basically, being programmer, do not want to become Sudoku professional player.
...
I think, there are few participants that participate in puzzle solving thread only to test his/her program skills, like myself, and they do not want to translate each and every move into some really professional way that uses expert in p&p.

Is that your excuse for not wanting to learn Eureka? It's your prerogative, but being (hopefully) a better programmer than a sudoku player I can't quite understand that attitude. Both activities require largely the same skill and tool sets, including an unambiguous language (or several) to express logic. For a programmer learning new languages should be fun anyway, and compared to programming languages sudoku languages are (syntactically) trivial!

Eureka is one such language. Its main purpose may be to communicate logic steps to others, but I claim that it also helps to produce them if you truly understand the philosophy behind it. The same is true about other sudoku languages which provide complementing points of view (e.g. set logic). Abstract thinking usually requires a language, and Eureka among others helps in sudoku thinking.

How is any of that relevant to you since you state that you have no interest in sudoku per se? Because you seem to have an interest in programming a sudoku solver anyway. I don't know what your goals with it are, but if you want it to mimic advanced human-style solving then you should probably understand the principles behind it. Learning Eureka would be a step in that direction. Then again, what do I know... I haven't even tried to program one!

[SteveG48]

Looks like you misunderstood my point. Of course anyone is free to post any applicable solution, and I would never suggest anything else. The simplest possible makes obviously the most sense too, so no one should be blamed for posting that!!

You're right, I did

While we're here, a comment on your multi-color solution. I'm surprised that you seldom use this. In ordinart day-to-day solving, that would have been my routine solution.

[SpAce]

You're right, I did

No problem. I guess I didn't communicate my intentions clearly.

While we're here, a comment on your multi-color solution. I'm surprised that you seldom use this. In ordinart day-to-day solving, that would have been my routine solution.

I find that equally surprising! As I recently mentioned here, I've considered multi-coloring an obsolete technique (at least for manual solving). For that reason I'd never before even tried it myself, because it just seemed more complicated than my usual coloring approach (GEM) without any obvious benefits. I'm still pretty sure that's true in most cases. However, multi-coloring has a certain elegance to it, and finding the deductions is more interesting (i.e. difficult).

I think I'll be experimenting with it more. I already did with today's puzzle where I used it in 3D mode (with multiple small Medusa clusters). That was definitely more interesting than my usual method, and I was happily surprised when I actually found useful deductions with it. The results were much harder to see, though. It also has obvious practical limitations when the number of concurrent clusters grows beyond available color pairs or human spotting capability.

In any case, I think multi-coloring would be a really powerful technique for a software solver, because it could analyze the interactions of all possible parity clusters at the same time free of physical or human limitations. I'm not sure but I guess champagne's Full Tagging method uses a somewhat similar approach and is successfully implemented at least in his own and Cenoman's solvers. I'd probably go with something like that if I ever tried my hand at programming a solver.

[rjamil]

Hi SpAce,

Is that your excuse for not wanting to learn Eureka?

Well, as an expert in Sudoku solving in p&p, how much you helpful for a programmer/beginner to write a routine/accurately translate each and every move that can be expressed in simple Sudoku language into compressed eureka notation with logic instead of philosophy?

Well, it is same as, not each and every spoken language is 100% accurately translated into another language.

FYI, initially I develop my solver based on bulk Sudoku solving with speed. It gradually included so many moves that are optimised for speed (in my way). But, then noticed that by increasing moves, speed become reduced. (Read here that 999_Springs mentioned that there are about ninety different ALS present in each Sudoku puzzle. Wish to collect all of them and try to search/code for speed.) I have coded those moves that are precalculated ways to search and easily available in exemplar form atm.

I have strong feeling that if bulk Sudoku puzzles are solved either minimum backtracking or correctly guess, with limited set of logical moves used beyond basic moves, then its fastest in speed solving too.

R. Jamil

[SpAce]

Hi rjamil,

Well, as an expert in Sudoku solving in p&p, how much you helpful for a programmer/beginner to write a routine/accurately translate each and every move that can be expressed in simple Sudoku language into compressed eureka notation with logic instead of philosophy?

I'm not sure if I understand what you're asking. Could you please rephrase that?

Well, it is same as, not each and every spoken language is 100% accurately translated into another language.

It's not the same. You're right that spoken (and written) human languages are hard to translate accurately. That's the big difference between human languages and unambiguous logic languages, such as programming languages and proper sudoku notations. A sudoku program could use Eureka not only as output but input as well (to validate a move and then execute it). I don't know any that do but it would certainly be possible to write a parser for Eureka. That's why it's so nice, because it can describe a move without any ambiguity.

FYI, my solver was initially based on bulk Sudoku solving with speed. It gradually included so many moves that are optimised for speed (in my way).

That's where our approaches differ. From what I understand, your solver looks for specific patterns in a specified order, and it can go no further unless more patterns are hardcoded into it. Maybe that's fast, I don't know, but it seems quite inefficient from a programming point of view, and it also limits its solving potential. You've already programmed a lot of patterns into it, and still it can only rarely find stte-moves for these puzzles (or so it seems). With a more generic approach it should be solving most of them easily.

My solving methods don't depend on memorizing any named moves or patterns at all. They depend on understanding the few fundamentals on which all solving techniques are based. If I were to code a solver program, I would use the same approach and make it as generic as possible. I don't see any reason to memorize (or hardcode) a lot of different patterns and their variants, because they all fall into a few generic families with shared logic. Almost all of them can be described accurately with Eureka.

[rjamil]

Hi SpAce,

I'm not sure if I understand what you're asking. Could you please rephrase that?

I mean, could you please help me to understand eureka notations or at least point me to some reading such material that will help to understand Sudoku eureka presentation of moves as compared with English literal text move.

R. Jamil

[SpAce]

I mean, could you please help me to understand eureka notations or at least point me to some reading such material that will help to understand Sudoku eureka presentation of moves as compared with English literal text move.

Of course! I'm happy to do that (and others are probably glad to help as well, I'm sure). I already started here. Would that kind of approach work for you, i.e. to see the Eureka versions of your own moves? (In the future I won't add so much clutter with the different variants, but I thought to show that there's rarely if ever just one way to see and write the same thing.) There's also a link to the Eureka documentation, although some of it is no longer valid information.