SudoQ wrote:Is the application using the method you describe and you refer to available?/SudoQ

The program is running on my computer. I do not plan to publish my python program, which is quite messy and not "pythonic". But I hope my algorithm description in that file is concise enough so everyone can have his/her own implementation, in their favourite languages. Hopefully, there will be major improvement to the algorithm /data structure, for example to address the memory explosion problem, and explore the parallelism

One thing I didn't have time to do but I think doable is to add an explanation feature.

Several algorithms are already known for solving any puzzle without guessing or trial and error. Consider the following: match the clues against the set of all possible solution grids. The solution grid that contains all of the clues is the solution. While highly impractical, there certainly isn't any guessing or trial and error involved. Solving methods like this one are considered brute force algorithms. Your approach also looks like a brute force approach, though I am not completely certain of that.

JasonLion wrote:Consider the following: match the clues against the set of all possible solution grids...

I do not agree this is really solving. This is checking a database. You need to have the database at the first place.

I won't say my method is a brute force, because it never need to assume any candidate. And all solutions (if there are multiple solutions) are generated simultaneously. To achieve that, you need to consider all candidates in the middle of computation, until a piece of evidence proves that they are invalid.

But I agree that there is a relationship between this algorithm and systematic search.

This kind of discussion requires clearer definitions of terms. You dismiss my first proposal because it is simply a "database". Yet, your approach involves enumerations of the possible positions of cogs, which look like "databases" to me. What is the logical difference between those two things?

JasonLion wrote:Yet, your approach involves enumerations of the possible positions of cogs, which look like "databases" to me. What is the logical difference between those two things?

The difference is: your proposal requires pre-existing "all solution grids", while mine computes whatever "database" that is necessary on the fly. Its size grows and shrinks and eventually becomes the exact set of solutions to the board. I think there is a big difference.

For one thing, you say your proposal is highly impractical, while mine yields a workable program.

0. Set the level to 0.1. Solve all singles and locked candidates2a. If the puzzle is solved, stop2b. If the level is 0 and the puzzle has no solution (a contradiction), there is no solution, stop2c. If the puzzle is still unsolved, continue with 3.2d. If the level is greater 0 and the puzzle has no solution, decrease the level and remove the candidate set in the higher level If this leaves a single, continue with 1.3. Find the first cell with the minimum number of candidates. Copy the grid (new "node"), increase the level, set the first candidate in this cell, continue with 1.

Brian made a very fast implementation in C++ in his bb_solver (bitbased, using lookup tables). It solves the 14258 extremely hard puzzles in champagne's list in 5 seconds.

"Guessing" has a logical element which you cant deny. Trivially even the simplist [single] insertion of a cell can be made assumptive. [e.g it cant be x because it has to be y] The only difference is the length of the process by which an insertion or elimination can be made.

I havnt looked at your program but i could ask how it decides where to start in the process.If it is able to solve without an assumptive process can you ascribe a "rating" as to how quick/how tricky/length of path etc

This might be a very useful by-product of your software.

Of course it would have to be isomorph invarient.

Switching off uniqueness as a method is also aesthetically pleasing to me !!!!!

It is very straightforward, though slow, to enumerate all possible solution grids on the fly. I see no logical difference between doing so and what you propose. In one sense I am simply extending the cog size to include all cells on the board. Certainly there is a practical difference of several orders of magnitude in the CPU time required. I didn't notice you mentioning CPU time requirements as a criteria before now. Previously you only mentioned avoiding guessing and avoiding trial and error. That is why I said you need to be precise in listing your definition of terms. What are your exact criteria for preferring one approach over another?

eleven wrote:Brian made a very fast implementation in C++ in his bb_solver (bitbased, using lookup tables). It solves the 14258 extremely hard puzzles in champagne's list in 5 seconds.

Wow, that is very great speed, many orders of magnitude faster than my implementation! But the main point here is that I am not using backtracking. But I will use this information in my revision of the paper.

My solver solved about 99.5% of those puzzles (in days). At the end of my paper I discuss the shortcoming of my approach, which is memory explosion, which prevents my 32-bit machine solve the remaining 0.5%. (unfortunately, 2GB is just a little to short). But I also give out the solutions there.

sdk_fan wrote:But the main point here is that I am not using backtracking.

If i understood right,what you are doing, the main difference to Brian's method is, that you are doing a breadth first and Brian a depth first search in your trees. This does not have any impact to questions like "is this or that one a guessing method ?" Its just a design decision, which can have impact to the peformance.

coloin wrote:I havnt looked at your program but i could ask how it decides where to start in the process.....

If it is able to solve without an assumptive process can you ascribe a "rating" as to how quick/how tricky/length of path etc. Of course it would have to be isomorph invarient.

Hi, Coloin, Your questions are difficult to answer but I think to the point, because I was thinking about rating!

For the first part: the process.. If you read section 3 (2 pages at most) of that paper, you can understand the process and your comment will be appreciated.

For the 2nd part.While I can say all solutions are bound to be found, there are many ways to find them. The main problem is that the sequence to combine 27 constraints is not decided. I use a heuristic to find a sequence that encourages early formation of cause-effect-back-to-cause circles among these constraints; at this stage I cannot guarantee this heuristics will invariantly find the isomorphic sequence on isomorphic invariants. (But I also do not see why it could behave differently). Nevertheless, even if the heuristic could be proved to work invariantly, it does not guaranteed to find the true optimal sequence for a particular puzzle. So my intuition says 'rating' is rather a subjective thing so I gave up the thought.

Last edited by sdk_fan on Thu Sep 29, 2011 4:34 pm, edited 1 time in total.

eleven wrote:If i understood right,what you are doing, the main difference to Brian's method is, that you are doing a breadth first and Brian a depth first search in your trees.

Hi, eleven, I am not thinking I am searching. A candidate is removed only because an evidence says it can't be there. But before that evidence (a constraint) is considered, that candidate should remain there. Here evidence is not gained by trying the candidate out first; but by checking the current constraint under consideration.

There is a tree involved, which is never complete (for searching purpose), until the last constraint (a row, a col, or a block) is considered. But at that moment the solutions are already decided, which is the tree itself.

There is no hint of breadth first process in my program. All traversing is done in depth first manner.