running the test on the virtual catalog using the gangster fills, I have seen a bug.
As I was not quite happy with the first draft, I reshaped the Gangster recognition and mapping in a way closer to what I did for the bands recognition.
The new code has been located in a separate file to prepare the final cleaning.
The new run of the entire catalog is on going with no bug at half way. So this version of the code is likely now bug free.
Next step will be, in the main thread of the virtual catalog, to apply the new band recognition to lower the response
rank <=> solution grid
solution grids per gangster
33 posts
• Page 3 of 3 • 1, 2, 3
Re: solution grids per gangster
by champagne » Thu Aug 29, 2024 2:51 pm
- champagne
- 2017 Supporter
- Posts: 7409
- Joined: 02 August 2007
- Location: France Brittany
Re: solution grids per gangster
by Sojourner9 » Mon Sep 02, 2024 9:23 pm
Hi champagne,
This is my understanding of what you are doing, correct me if I am wrong.
You are looking at the make up of a minLex grid, trying to come up with an index 0..<5472730538 to be used as an index into your catalog of 18 clue puzzles?
And a reverse lookup table as well, maybe.
Would any Int64 work, or do you need them to be in the above range?
I can reduce any grid to less than 64 bits using what I call minRep. So the act of finding the minimum representative grid also gives you the index.
Would the minRep be good enough for the catalog index?
I have Nmin enumerated as 5472730538 Int64 minReps currently separated into about 180 files and they are in ascending order.
I could probably make this into more files for finer resolution. If you had a computer with 44Gig of ram you could load it into memory.
There is a lot of redundancy in the integer, it might be able to be made into a linked list of some usable size again with enough memery.
I guess I did use the B1B2B3B4B7 method.
Since you don't need reordering in your catalog, any puzzle can be reduced to 1 64 bit integers for the grid and 3 32 bit Integers (3x27 bits) for the puzzle, which is 5 Int32s.
Or 1 Int64 for the solution grid and a list containing 3 Int32s for each 18 clue puzzles using that grid.
This is my understanding of what you are doing, correct me if I am wrong.
You are looking at the make up of a minLex grid, trying to come up with an index 0..<5472730538 to be used as an index into your catalog of 18 clue puzzles?
And a reverse lookup table as well, maybe.
Would any Int64 work, or do you need them to be in the above range?
I can reduce any grid to less than 64 bits using what I call minRep. So the act of finding the minimum representative grid also gives you the index.
Would the minRep be good enough for the catalog index?
I have Nmin enumerated as 5472730538 Int64 minReps currently separated into about 180 files and they are in ascending order.
I could probably make this into more files for finer resolution. If you had a computer with 44Gig of ram you could load it into memory.
There is a lot of redundancy in the integer, it might be able to be made into a linked list of some usable size again with enough memery.
I guess I did use the B1B2B3B4B7 method.
Since you don't need reordering in your catalog, any puzzle can be reduced to 1 64 bit integers for the grid and 3 32 bit Integers (3x27 bits) for the puzzle, which is 5 Int32s.
Or 1 Int64 for the solution grid and a list containing 3 Int32s for each 18 clue puzzles using that grid.
- Sojourner9
- Posts: 36
- Joined: 10 March 2018
Re: solution grids per gangster
by champagne » Tue Sep 03, 2024 7:36 pm
Hi Sojourner9,
Surely, I had in mind a way to store, later, a file of 18 clues puzzles, but immediately, the cooperation to the project of our lost friend “Mathimagics” came up with another use of the min lexical catalog.
To make it simple, “Mathimagcs” tried to define, for any solution grid, the minimum number of clues of a valid puzzle.
This requires in any form a 5472730538 list of “minimal values” and links to the corresponding solutions grids.
Up to now, this has been possible using a file of the catalog 5472730538 solution grids.
Mladen gave a design for a 10 bytes per solution grid file
http://forum.enjoysudoku.com/high-density-files-for-solution-grids-and-18-clues-puzzles-t42669.html
If I get it well, you have other options to propose.
I took a completely different option. We know that we have exactly 5472730538 solution grids; Would it be possible to have a link {solution grid <=> rank} using no file.
Using the min lexical morph of the solution grids was evidence, it is the commonly agreed representation of the catalog. Then the problem as I saw it could be phrased as
Have an efficient catalog builder producing it in min lexical order,
Try to turn it to a partially direct link using indexes and any seen possible improvement.
If you reach a response far below the second, then you have a virtual catalog.
The size of the “virtual catalog “ is then the size of the “DLL” giving the dual link. Say around 2MB, far below your 44 GB of Ram.
Where we are, we can produce the entire catalog in 11 hours with my old i7 (enumeration mode), with a direct response {solution grid <=> rank} in some milliseconds in the worst case.
I am finishing the implementation of a new” Band recognition and mapping” adjusted to this process requirements , and I have still in the “to do list” some ideas of “coloin”, so the final target for the entire catalog building could be significantly below 10 hours with a parallel reduction of the average response.
At the end, this gives no room for any other definition of the rank in my work than the min lexical order.
But the best way to store a 18 clues file remains open. Using the solution grid rank plus a 81 bit field is one option among others.
Surely, I had in mind a way to store, later, a file of 18 clues puzzles, but immediately, the cooperation to the project of our lost friend “Mathimagics” came up with another use of the min lexical catalog.
To make it simple, “Mathimagcs” tried to define, for any solution grid, the minimum number of clues of a valid puzzle.
This requires in any form a 5472730538 list of “minimal values” and links to the corresponding solutions grids.
Up to now, this has been possible using a file of the catalog 5472730538 solution grids.
Mladen gave a design for a 10 bytes per solution grid file
http://forum.enjoysudoku.com/high-density-files-for-solution-grids-and-18-clues-puzzles-t42669.html
If I get it well, you have other options to propose.
I took a completely different option. We know that we have exactly 5472730538 solution grids; Would it be possible to have a link {solution grid <=> rank} using no file.
Using the min lexical morph of the solution grids was evidence, it is the commonly agreed representation of the catalog. Then the problem as I saw it could be phrased as
Have an efficient catalog builder producing it in min lexical order,
Try to turn it to a partially direct link using indexes and any seen possible improvement.
If you reach a response far below the second, then you have a virtual catalog.
The size of the “virtual catalog “ is then the size of the “DLL” giving the dual link. Say around 2MB, far below your 44 GB of Ram.
Where we are, we can produce the entire catalog in 11 hours with my old i7 (enumeration mode), with a direct response {solution grid <=> rank} in some milliseconds in the worst case.
I am finishing the implementation of a new” Band recognition and mapping” adjusted to this process requirements , and I have still in the “to do list” some ideas of “coloin”, so the final target for the entire catalog building could be significantly below 10 hours with a parallel reduction of the average response.
At the end, this gives no room for any other definition of the rank in my work than the min lexical order.
But the best way to store a 18 clues file remains open. Using the solution grid rank plus a 81 bit field is one option among others.
- champagne
- 2017 Supporter
- Posts: 7409
- Joined: 02 August 2007
- Location: France Brittany
33 posts
• Page 3 of 3 • 1, 2, 3
