The New Sudoku Players' Forum

[denis_berthier]

.
I could make the changes and compile the result.

Using the following 11.7 puzzle as an example (1st in ph2010) and with nothing running at the same time:

Code: Select all

98.7.....7.....6....6.5.....4...5.3...79..5......2...1..85..9......1...4.....3.2.

(RAM is the largest size reached during the process).


For SER:
time java -jar SudokuExplainer.jar diuf.sudoku.test.serate 98.7.....7.....6....6.5.....4...5.3...79..5......2...1..85..9......1...4.....3.2.
1.95 GB
java -cp SudokuExplainer.jar diuf.sudoku.test.serate --format=%r 1540,65s user 21,72s system 104% cpu 24:50,43 total
Real total processor time: 1540,65s + user 21,72s system = 1561.93 s

For PGX:
time java -jar PGXplainer.jar 98.7.....7.....6....6.5.....4...5.3...79..5......2...1..85..9......1...4.....3.2.
6.24 GB
java -jar PGXplainer.jar 1508,03s user 19,59s system 404% cpu 6:17,43 total
Real total processor time: 1508,03s user + 19,59s system = 1527.62 s

For your modif of PGE:
time java -jar modif-PGEplainer.jar 98.7.....7.....6....6.5.....4...5.3...79..5......2...1..85..9......1...4.....3.2.
5.98 GB
java -jar PGExplainer.jar 574,52s user 13,67s system 308% cpu 3:10,59 total
Real total processor time: 574,52s user + 13,67s system = 588.19

On this example, it seems that your modifications really reduce computation time.

For a software on GitHub, the standard procedure for you would be to make a pull request to 1to9only. Let's see what he does with it.


Now, for people involved in looking for the "hardest" puzzles and in order to compare also with the computations for the BpB classification, using the SHC (this puzzle is in B6B):
time java -jar SHC.jar BpB -puzzle 98.7.....7.....6....6.5.....4...5.3...79..5......2...1..85..9......1...4.....3.2.
2.08 GB
java -jar SHC.jar BpB -puzzle 13,40s user 0,94s system 97% cpu 14,730 total
Real total processor time: 13,40s user + 0,94s system = 14.34 s

[1to9only]

PGE is a faster SE meant for the Patterns Game, which is now dead! So I dont expect any changes to PGE/PGX.
You can clone PGE/PGX from Github and make changes to suit your projects.

[denis_berthier]

.
Without being a java programmer, I could include creint's changes into PGXplainer (instead of PGExplainer). Indeed, the two changes are independent and you can make the above ones given by creint directly into PGXplainer instead of PGExplainer.


For the same puzzle as before:
java -jar PGXplainer.jar 571,75s user 13,05s system 319% cpu 3:03,08 total
Real total processor time: 571,75s user + 13,05s system = 584.8s = [b]584.8s/b]
Same gain as with the PGE modified version

Of course, this would require much more extensive testing, but I have no time for this right now.

If anyone wants the resulting version of PGX, PM me.
[Edit]: after someone asked, I created a link:
https://drive.google.com/file/d/1vxl21CkrY_r6Vv5Cbc8DIHmgo_F2S02_/view?usp=share_link
.

[1to9only]

FWIW,
SE, PGE, PGX, rate Loki as ED=11.9/1.2/1.2
skfr, my own mods of lksudoku's batch, creint's batch mods, rate Loki as ED=11.8/1.2/1.2

[creint]

Then there is probably a bug:

Code: Select all

....5..........7....34.6.8..23....8...34.6...1.3..............9123......1.3..6....234.6..9.234....9..34.6..9.23.5.7....34567..1.3.5.7.9..345....12....7.........8..234.6.8.1..........34.6.89.2....78...3456.....3.....9..345.7...23.5.7....3.567....3...7.9..3.5...91.............6..........8...3.5.7....3.5.7.....4......2.........34.67....345......34.67..1..........3.5.7...2..............8...3.5.7..........9..3...78...3.5..8..2.........3.5.7..........9...4.....1.............6.....3.5.7..1.34...89..34...89..345.7.9..3.5.7...2............6.....3.5.7.........891...5....1.3...........6.....3.5.7..........9..3.5.7.........8..2.......1.3.5.7.....4......23...789.23....89..3.5.789...4.....1..........3.5.7.......6..........89..3.5.7..

PGX gives possibility: 11.8 -8r3c1 -8r9c3

PGX 11.8 -9r2c6:

Code: Select all

....5..........7....34.6.8..23....8...34.6...1.3..............9123......1.3..6....234.6..9.234....9..34.6..9.23.5.7....34567..1.3.5.7....345....12....7.........8..234.6.8.1..........34.6.89.2....78...3456.....3.....9..345.7...23.5.7....3.567....3...7.9..3.5...91.............6..........8...3.5.7....3.5.7.....4......2.........34.67....345......34.67..1..........3.5.7...2..............8...3.5.7..........9..3...78...3.5..8..2.........3.5.7..........9...4.....1.............6.....3.5.7..1.34...89..34...89..345.7.9..3.5.7...2............6.....3.5.7.........891...5....1.3...........6.....3.5.7..........9..3.5.7.........8..2.......1.3.5.7.....4......23...789.23....89..3.5.789...4.....1..........3.5.7.......6..........89..3.5.7..

PGX does Single 9r3c6 -9r3c3:

Code: Select all

....5..........7....34.6.8..23....8...34.6...1.3..............9123......1.3..6....234.6..9.234....9..34.6..9.23.5.7....34567..1.3.5.7....345....12....7.........8..234.6.8.1..........34.6.8..2....78...3456...........9..345.7...23.5.7....3.567....3...7.9..3.5...91.............6..........8...3.5.7....3.5.7.....4......2.........34.67....345......34.67..1..........3.5.7...2..............8...3.5.7..........9..3...78...3.5..8..2.........3.5.7..........9...4.....1.............6.....3.5.7..1.34...89..34...89..345.7.9..3.5.7...2............6.....3.5.7.........891...5....1.3...........6.....3.5.7..........9..3.5.7.........8..2.......1.3.5.7.....4......23...789.23....89..3.5.789...4.....1..........3.5.7.......6..........89..3.5.7..

PGX then gives possibility: 11.9 -8r3c1 -8r9c3

So removing candidates makes it harder?

[denis_berthier]

.
The bug is the old conceptual bug in SER: the use of uniqueness. Try to use it without uniqueness (with the -M option].

[creint]

Uniqueness is not the problem.
Removing otherRules.add(new Fisherman(2)); in chaining.java getAdvancedPotentials will give the 2 11.8 instead of the 5 11.9 when that code is in place.

[denis_berthier]

Uniqueness is not the problem.
Removing otherRules.add(new Fisherman(2)); in chaining.java getAdvancedPotentials will give the 2 11.8 instead of the 5 11.9 when that code is in place.

OK, I see.
This kind of problem is generally due to uniqueness.
In the present case, it must be due to another conceptual problem with SER: the non-confluence property of the "rules" defining the various levels of SER. If you change the order in which rules are applied (which you do by deleting one rule), you get a different resolution path.

[denis_berthier]

.
Without being a java programmer, I could include creint's changes into PGXplainer (instead of PGExplainer). Indeed, the two changes are independent and you can make the above ones given by creint directly into PGXplainer instead of PGExplainer.
[...]
If anyone wants the resulting version of PGX, PM me.
[Edit]: after someone asked, I created a link:
https://drive.google.com/file/d/1vxl21CkrY_r6Vv5Cbc8DIHmgo_F2S02_/view?usp=share_link

As I have now used this version extensively to rate the 5,926,343 minimal controlled-bias puzzles, I have given it a name (FPGX, F for "faster") and added it to the PROGRAMS part of the controlled-bias repository on GitHub: https://github.com/denis-berthier/Controlled-bias_Sudoku_generator_and_collection
where I've also added a specific README.md file listing the modifications made from Sudoku Explainer.

1to9only and creint, could you have a look at this file, check that I made no errors and/or suggest changes? https://github.com/denis-berthier/Controlled-bias_Sudoku_generator_and_collection/tree/master/PROGRAMS/FPGX#readme

FPGX is the version I highly recommend to use in replacement of SER: it is much faster and it solves some of the problems of isomorphism dependency.
It seems there may appear differences of 0.1 in the SER and FPGX ratings - but, considering that SER thresholds are arbitrary, such differences are totally meaningless.
In my estimates, the time ratio FPGX/SER (i.e. total processor time, not apparent time) varies between 0.7 and 0.5.
.