CSP-Rules, SudoRules, KakuRules...

Programs which generate, solve, and analyze Sudoku puzzles

Re: CSP-Rules, SudoRules, KakuRules...

Postby denis_berthier » Fri Jan 26, 2024 5:53 am

.
In order to allow the easy calculation of expansions of puzzles, I added to SudoRules (https://github.com/denis-berthier/CSP-Rules-V2.1) a function "record-expansions-n-grids-after-first-p-from-text-file", with syntax:

Code: Select all
(record-expansions-n-grids-after-first-p-from-text-file ?puzzles-file ?p ?n ?expansions-file)

As usual:
Code: Select all
?puzzles-file and ?expansions-file are file names
?p is the number of puzzles to be skipped (it will generally be 0)
?n is the number of puzzles to be expanded
?p + ?n is supposed to be ≤ the length of ?puzzles-file
the length of ?expansions-file will be ?n


Note that this function can be used for multiple purposes, depending on which rules are selected in the configuration file. The two most typical ones are:
- select only the rules in BRT (i.e. nothing in the configuration file) and you will get the file of expansions by Singles;
- select only DFS and you will get the file of solutions.

Warning: any other set of rules with the confluence property can be selected to make expansions with this function, but only the asserted values are taken into account in the results (eliminated candidates are not: i.e. the result is a Sudoku not a Sukaku). Whether such expansions may have any usefulness is up to the user to decide. IMO, they don't, because what they keep of the expansion process is arbitrary.
.
denis_berthier
2010 Supporter
 
Posts: 4002
Joined: 19 June 2007
Location: Paris

Re: CSP-Rules, SudoRules, KakuRules...

Postby denis_berthier » Mon Jan 29, 2024 11:41 am

.
I updated the Controlled Bias Collection (https://github.com/denis-berthier/Controlled-bias_Sudoku_generator_and_collection) by adding more gB-ratings.
The purpose is not to change the stats (they are already quite precise, but to find cases of largest differences between the 4 ratings (W, gW, B, gB). See http://forum.enjoysudoku.com/pattern-based-constraint-satisfaction-2nd-3rd-eds-t32567.html for comments about the reults.
The collection with computed gB ratings now has over 3M puzzles (more than half of the total collection).

[Edit 2024 Feb. 03: the gB ratings are now computed for the whole collection of ~6M puzzles.]
.
denis_berthier
2010 Supporter
 
Posts: 4002
Joined: 19 June 2007
Location: Paris

Re: CSP-Rules, SudoRules, KakuRules...

Postby denis_berthier » Fri May 03, 2024 9:14 am

.
Addition of global variable ?*Imp630-list* for the easier tracking of impossible patterns in functions of type "solve-file".
A the end of the function, ?*Imp630-list* contains the IDs of the puzzles that have an impossible pattern (among those selected in the configuration file).

This comes in addition to the already existing: ?*tridagon-list* and ?*degenerate-cyclic-tridagon-list*.
.
denis_berthier
2010 Supporter
 
Posts: 4002
Joined: 19 June 2007
Location: Paris

Re: CSP-Rules, SudoRules, KakuRules...

Postby denis_berthier » Fri May 17, 2024 7:02 am

.
In order to make it easier to track (non-degenerate) tridagons and degenerate-cyclic tridagons when solving files of puzzles, at the end of calculations, the two global variables:
?*tridagon-list* and ?*degenerate-cyclic-tridagon-list* now contain the lists of puzzles numbers having respectively:
- a (non-degenerate) tridagon,
- either a non-degenerate or a degenerate-cyclic tridagon.

(The difference with before is, when both rules were activated together with other rules, ?*degenerate-cyclic-tridagon-list* might not have included all the non-degenerate cases (in case a puzzle was solved before the degenerate form was found) and some union of the two lists was necessary. This doesn't change my previously reported results, as I did this union). But it will avoid possible errors.
.
denis_berthier
2010 Supporter
 
Posts: 4002
Joined: 19 June 2007
Location: Paris

Re: CSP-Rules, SudoRules, KakuRules...

Postby denis_berthier » Sat May 18, 2024 4:55 am

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.
.
denis_berthier
2010 Supporter
 
Posts: 4002
Joined: 19 June 2007
Location: Paris

Previous

Return to Software