3.77us Solver(2.8G CPU, TestCase:17Sodoku)

Programs which generate, solve, and analyze Sudoku puzzles

Re: 3.77us Solver(2.8G CPU, TestCase:17Sodoku)

Postby emerentius_ » Sun Jun 24, 2018 10:25 pm

dobrichev wrote:And that did not stop you from licensing the code without even mentioning the original author and other contributors?

I don't see what relation cryptic names, of which there was no shortage of, have to anything, really. I can add a contribution header to the file of course, but it's not like I've been passing off other people's work as my own. The library in that repo has roundabout 0 users, was never advertised anywhere (yet) and only mentioned here where it's clear to anyone that the solver was a collaborative work of several people.
emerentius_
 
Posts: 15
Joined: 09 January 2018

Re: 3.77us Solver(2.8G CPU, TestCase:17Sodoku)

Postby Patrice » Thu Jan 03, 2019 1:31 pm

Hello guys,
Did you publish a new version of JCZsolve ?
I found V1.0 as attached file in JasonLion post
3-77us-solver-2-8g-cpu-testcase-17sodoku-t30470-219.html

but i did not noticed something new meanwhile a lot of discussions on improvements

Happy new year 2019 !
Patrice
 
Posts: 1934
Joined: 07 November 2010
Location: Paris France

Re: 3.77us Solver(2.8G CPU, TestCase:17Sodoku)

Postby champagne » Thu Jan 03, 2019 6:21 pm

Patrice wrote:Hello guys,
Did you publish a new version of JCZsolve ?
I found V1.0 as attached file in JasonLion post
3-77us-solver-2-8g-cpu-testcase-17sodoku-t30470-219.html

but i did not noticed something new meanwhile a lot of discussions on improvements

Happy new year 2019 !


Hi Patrice,

Where we are, it's not easy to produce a better code. I failed in several attempts to do it.
I am testing for the 17 clues search with the 656 clues/stack distribution new ideas. This is for the time being in a 2 bands (6 rows) mode with a known solution grid, but the same strategy can be applied in a slightly different way in the general case.

I hope to test this on the beach side in the southern hemisphere end of January beginning of February. I'll come back here if the results are good.
champagne
2017 Supporter
 
Posts: 6742
Joined: 02 August 2007
Location: France Brittany

Re: 3.77us Solver(2.8G CPU, TestCase:17Sodoku)

Postby emerentius_ » Fri Jan 04, 2019 1:08 am

Patrice wrote:Did you publish a new version of JCZsolve ?


All the improvements I talked about are implemented in the Rust version of the solver which is part of my sudoku library on github. Like I wrote on the last page of this thread, it's 10-20% faster than the version you've linked on any collection I've tested.

If you're looking for source code of the solver, that's in the linked repository. If you want a binary, I have the code for one here, but it requires a rust compiler of course.
emerentius_
 
Posts: 15
Joined: 09 January 2018

Re: 3.77us Solver(2.8G CPU, TestCase:17Sodoku)

Postby champagne » Tue Jan 08, 2019 12:43 pm

Patrice wrote:Hello guys,
Did you publish a new version of JCZsolve ?
I found V1.0 as attached file in JasonLion post
3-77us-solver-2-8g-cpu-testcase-17sodoku-t30470-219.html

but i did not noticed something new meanwhile a lot of discussions on improvements

Happy new year 2019 !


Hi Patrice,
back to this post.

One key question is "why do you need a fast brute force solver".
We can immediately discard the check that a given puzzle posted here or there is valid. This will not be a critical step.

The classical cases are

is this puzzle "valid" (one and only one solution)
is this puzzle minimal.

In the second case most of the sub puzzles will not have a unique solution
In the first cases, a huge majority of puzzles will have many solutions, most of the rest will have no solution.

In fact, a valid puzzle is a rarity for guys working in this field. BTW, a valid puzzle is a kind of worst case for a brute force (may be just followed by a puzzle with no solution )

Most of the "primary benchmarks" are done on valid puzzles files. This can tell you if the order of magnitude of the average run time is correct, but is in general totally misleading to define the best tool for a given task.

It happens that in my 17 clues search improvements I was at the point where the general brute force plays a role. So, I am working on the topic.

I forgot another key point. Most of the puzzles, if valid, are in the range "very easy" to "SE rating <8.0".
A brute force performing well must be highly efficient for such puzzles.

zhouyundong_2012's code performs very well in this area, so don't expect an improvement deviating much out of this code unless a new very efficient idea comes out.

And the benchmark to use is very difficult to assess, the users will have to rely on an acceptable code and make their own judgement depending on the problem to solve.

.
champagne
2017 Supporter
 
Posts: 6742
Joined: 02 August 2007
Location: France Brittany

Previous

Return to Software