The New Sudoku Players' Forum

[RSW]

I may combine some of the colours of the digits displayed on the grid into groups according to the level of the solving technique.

As for choosing the solve order, it can be operated fully manually, where the user clicks the button according which technique is to be applied, and it will do a single scan of the grid to find that pattern. If found, it shows the resulting exclusions.

Back to the original subject of the technique that I referred to as "Musical Chairs", I've been reading up on Aligned Pair Exclusions, and I think I may be able to upgrade my Musical Chairs code to find more than the trivial cases that it now detects.

[SpAce]

I may combine some of the colours of the digits displayed on the grid into groups according to the level of the solving technique.

Ok. That answers 1/3 of the concerns I presented about the coloring approach. Please don't get me wrong. I'm certainly not telling what you should or shouldn't do with your own solver, but I'm just asking questions to help you double-check that you've thought everything through. For example, let's assume that you have a cell with four candidates to begin with. You eliminate one of them with an X-Wing (color 1), later another one with an AIC (color 2), and eventually the third one with a Naked Pair (color 3). Now you can solve the cell with a Naked Single (color 4). Which color will the placed digit have?

As for choosing the solve order, it can be operated fully manually, where the user clicks the button according which technique is to be applied, and it will do a single scan of the grid to find that pattern. If found, it shows the resulting exclusions.

I got that the first time, but I see now that I communicated poorly. You also said that you'd added a single button to solve the puzzle completely, and I was talking about that. It wasn't (and isn't) clear if the user can specify the techniques and their order when that button is clicked. In my experience such configurability is a very useful feature. Even more useful for manual solving is a similarly configurable "Solve up to" button which can bypass (subjectively) trivial or uninteresting parts. For example, when solving the daily one-trick-ponies on this forum, it's nice to be able to skip the basics with one click and get to work immediately. In fact, I'd like to have at least three of those buttons: one for singles, one for basics, and one for a customized set.

Back to the original subject of the technique that I referred to as "Musical Chairs", I've been reading up on Aligned Pair Exclusions, and I think I may be able to upgrade my Musical Chairs code to find more than the trivial cases that it now detects.

If you really like that technique, go for it, especially since you already have part of it implemented and you like to use it in manual solving.

Personally, I'd skip APE and anything resembling it, or at least give it a very low priority. It's one of the very few techniques that I've never applied in a live puzzle myself, and if a software solver has it in its repertoire, I disable it. It has a distinct taste of T&E, just in a simple form, and I don't want to use T&E in puzzles that don't need it. Also, as far as I know, any of its easily applicable forms can be replaced more elegantly with ALS patterns which often have more eliminations too. I rather use those instead, especially since I spot them much more naturally (like other chains).

Again, please don't get me wrong. I'm definitely not telling or even attempting to tell what you should do with your solver, or how you should solve puzzles. I'm just telling how I feel about that particular technique, and I'm pretty sure I'm not alone in my aversion. There are so many nicer and more effective techniques available that I'd concentrate on those first. You have every right to feel otherwise, of course. In fact, I think it's great that different people prefer different techniques. I've learned a lot because of that. Perhaps you can find and show me an example where APE (or its variant) is in fact a preferable option and hard to replace with anything else. If you do, then I've learned something new, and I would like that.

[RSW]

I'm just asking questions to help you double-check that you've thought everything through. For example, let's assume that you have a cell with four candidates to begin with. You eliminate one of them with an X-Wing (color 1), later another one with an AIC (color 2), and eventually the third one with a Naked Pair (color 3). Now you can solve the cell with a Naked Single (color 4). Which color will the placed digit have?

Yes, I'd realized this problem almost as soon as I implemented the colouring scheme. A possible solution to the ambiguity is that when a candidate is eliminated from a cell due to a particular technique, then a colour could be assigned on a priority basis. When the cell is completely solved, then the colour associated with the technique having the highest difficulty level could be used. Or, I may abandon the colours altogether.

It wasn't (and isn't) clear if the user can specify the techniques and their order when that button is clicked. In my experience such configurability is a very useful feature. Even more useful for manual solving is a similarly configurable "Solve up to" button which can bypass (subjectively) trivial or uninteresting parts. For example, when solving the daily one-trick-ponies on this forum, it's nice to be able to skip the basics with one click and get to work immediately. In fact, I'd like to have at least three of those buttons: one for singles, one for basics, and one for a customized set.

Turning the various techniques off and on is an easy feature to add. I can add a set of checkboxes for them. As for determining the order, that would be a bit more complicated, but not difficult.

Personally, I'd skip APE and anything resembling it, or at least give it a very low priority.

It depends a lot on how easy it is to implement. I prefer to focus on the basics first, but if I happen to think of an easy way to implement a more advanced technique, then I'll go ahead and do it. Since computers do things differently than humans, some techniques that are difficult for a human to grasp, may have a simple mathematical or logical basis that is easy to code into a program, and vice versa.

Like you, I don't like having to resort to techniques that lean towards T&E. I'd rather stick with purely logical techniques.

Last night, while ruminating on what to implement next, I thought of a straightforward way to do XYZ-wings. So, that's probably now at the top of the priority list.

[SpAce]

Yes, I'd realized this problem almost as soon as I implemented the colouring scheme. A possible solution to the ambiguity is that when a candidate is eliminated from a cell due to a particular technique, then a colour could be assigned on a priority basis. When the cell is completely solved, then the colour associated with the technique having the highest difficulty level could be used. Or, I may abandon the colours altogether.

I wouldn't abandon them altogether. With some tweaking your approach would work as a nice visual aid to analyze a solved puzzle afterwards. When used like that the colors could be associated with the eliminated candidates directly, and the above-mentioned problem would be avoided. I'd actually like such a feature giving an idea of how difficult each elimination was and marking the bottlenecks of the puzzle. Such a coloring scheme would work well with your candidate circles which, by the way, can also be used to encode lots of more useful information (like I do when solving harder puzzles on p&p).

So, I think it could be a nice post-game analysis tool. However, while still solving it's more important to have visual aids that help the player advance the puzzle, and I don't think this one does (plus it disrupts other coloring methods that do). While the game is on, I wouldn't waste valuable grid real-estate for something that doesn't directly help the player. Of course it could be an optionally selectable view, but as the default view it seems less useful and possibly confusing.

It depends a lot on how easy it is to implement. I prefer to focus on the basics first, but if I happen to think of an easy way to implement a more advanced technique, then I'll go ahead and do it. Since computers do things differently than humans, some techniques that are difficult for a human to grasp, may have a simple mathematical or logical basis that is easy to code into a program, and vice versa.

Of course. There lies a potential conflict, however. If you want your program to help a human player learn advanced techniques, you should concentrate on techniques that are humanly applicable (or preferable) and visual aids that help with them. That's a very different (and probably harder) problem than writing a program that solves a puzzle as efficiently as possible on its own. It seems to me that your approach is still a bit ambivalent about which way it's leaning, but I could be wrong.

Like you, I don't like having to resort to techniques that lean towards T&E. I'd rather stick with purely logical techniques.

Strictly speaking, T&E is a purely logical technique (especially if no T&S steps are accepted). It's just not very elegant or fun, or even efficient when recognizable solving patterns are around. A more valid comparison can be made between T&E and pattern-based techniques, but even they are just two sides of the same coin. The distinctive difference between them is that T&E starts with an assumption, and the only thing that can be concluded is the validity of that assumption (best case is a contradiction that proves the assumption false; other cases are worthless unless T&S is accepted). On the other hand, (most) patterns prove something about external candidates and depend on no assumptions (the pattern and its logic is valid even if there's nothing to eliminate). Every pattern-based elimination can be achieved with T&E, however, and it's also a simple way to double-check them (just assume the to-be-eliminated candidate ON and see if you get a contradiction). To me APE seems more like a multi-case T&E procedure than a pattern-based technique.

Last night, while ruminating on what to implement next, I thought of a straightforward way to do XYZ-wings. So, that's probably now at the top of the priority list.

The ease of implementing is a valid way to prioritize; nothing wrong with that strategy. However, I'd probably go with something else if the priority is to implement techniques that have the most solving potential and/or are easiest for human players. XYZ-Wing is one of the rarest techniques I've used in manual solving, and even then it's rarely effective. You'd probably get more bang for the buck with several other simple patterns that are more common, easier to spot, and usually more effective.

Generally speaking, instead of coding a zillion named patterns as separate entities I'd probably figure out a way to implement generic AICs as soon as possible, because almost all of those patterns are short AICs anyway (including XYZ-Wings, just with an ALS twist). Once that's working, then the special cases can be associated with their common pattern names without coding each one separately. That was my approach for manual solving too.

If individual patterns are prioritized, the top three (+1) of my list would probably be:

1. UR Type 1 (very common and often easiest to spot, even without candidates; Types 2 and 4 also easy)
2. X-Wing (very common and easy to spot, even without candidates)
3. Skyscraper (very common, and easy to learn after X-Wing; seems to be the king of Turbot Fishes)
4. BUG+1 (not that common, but a trivial way to solve a puzzle when available)

In my experience, those simple techniques alone solve most of the easiest non-basic puzzles. After that it's more of a matter of taste what comes next.