SudoRules user wrote:What has changed is not clear....
First, if you are using SudoRules to solve puzzles one by one, nothing has changed.
There are 3 resolution rules for tridagons:
- one for the simplest 1 guardian case of the non-degenerate tridagon: it concludes on the deletion of the 3 tridagon candidates in the target cell (the resulting Single is dealt with by the basic Singles rule), and it sets global variable ?*has-tridagon* to TRUE;
- one for the multi-guardian case of the non-degenerate tridagon: it asserts a tridagon-ORk-relation,
k≥2, and it sets global variable ?*has-tridagon* to TRUE;
- one for the degenerate-cyclic tridagon: it asserts a tridagon-ORk-relation,
k≥1 (when k=1, the resulting Single is dealt with by an OR1 rule that does the same job as Singles), and it sets global variable ?*has-degenerate-cyclic-tridagon* to TRUE.
(The two non-degenerate cases could have been dealt with the same way, but the difference is the result of historical development and is irrelevant here.)
Note: the variables are set to TRUE in a way totally independent of the usefulness of the tridagon. They just mean that the pattern has been detected.
Note: the three rules can be activated almost independently by setting the corresponding global variable (?*Tridagons*, ?*Anti-Tridagons* or ?*Degen-Cyclic-Anti-Tridagons*) to TRUE in the configuration file. (?*Anti-Tridagons* automatically implies *Tridagons*)
For efficiency reasons, the degenerate-cyclic tridagon rule doesn't have explicit conditions for degeneracy, so that it also covers the non-degenerate case. Also, it has lower priority than the non-degenerate rules.
In case you solve files of puzzles, variables ?*has-tridagon* and ?*has-degenerate-cyclic-tridagon* are used by the solve-files functions to add the puzzle number to the corresponding global variable list ?*tridagon-list* or ?*degenerate-cyclic-tridagon-list* at the end of resolution of each puzzle.
There are puzzles that can be solved by the simplest tridagon rule and Triplets. In such a case, the degenerate-cyclic tridagon doesn't get a chance to be identified before the solution is reached: ?*has-tridagon* is set to TRUE but ?*has-degenerate-cyclic-tridagon* is not.
Before the last modification, this implied that the puzzle appeared in ?*tridagon-list* but not in ?*degenerate-cyclic-tridagon-list*. This wasn't a problem for me because I knew how it works and I did a union of the two lists, but it may have been confusing for other users.
(Why activate Triplets when checking the presence of tridagons? It is indeed very useful to eliminate trivial cases in which Triplets destroy the pattern before it can be identified.)
So, after the last changes, in every possible case, at the end of computations:
- ?*tridagon-list* is the list of all the puzzles that have a non-degenerate tridagon,
- ?*degenerate-cyclic-tridagon-list* is the list of all the puzzles that have either a non-degenerate or a degenerate-cyclic tridagon.
Note: I originally introduced these lists for my own research purposes. I hadn't planned to document them. But that's done.
.