Hi debblez,
A little more after Mathimagics last post.
In the LCT project, Mathimagics did a significant step using the vicinity search to detect solution grids having one or more 18's.
He had to stop when the yield was too bad.
If we know that we have only 49158 ED 17s, the number of ED 18 is huge. I don't have an estimate of this number, but Blue and Mathimagics made an estimate that about 20% of the solution grids have at least one 18. As an average 5 18s per active solution grid is a reasonable bet, We should at the end have more then 5 billions ED 18s.
Blue delivered (not public) a DLL performing well for the 18 search in a unique solution grid. Unhappily, we don't have the sources and Blue withdrew from the project for personal reasons.
I suggested to Mathimagics to apply an improved process derived from the 17 scan to restart the project. Blue's DLL performance showed that we had room for that.
The first challenge was to guess how blue improved his process and to try to reach a similar or better run time. This is a hard job. There is no true economical challenge in the results, so it remains a kind of hobby research on my side and nobody was prepared to work with me on this code.
2 month ago, we were very close to have a beta test with a code approaching the DLL performance (but working in the frame used to scan the 17 field).
Thinking with Mathimagics of the best process to apply in his project, we came to the conclusion that we should change one of the main constraints of blue's design.
This leaded to another change in the last part of the process and pushed to another strategy to implement it.
This is of small (if any) interest for the users, but any change in this process requires many many tests not easy to design.
As wrote Mathimagics, we have now in hands a sound basis, with a code that seems faster than Blue's DLL, I agree that in March, we should have solved several minor performance issues and be in a position to start a beta test version for Mathimagics's project.
I chose to make public the draft of the code. This is consistent with my age and the risks attached the way this is implemented.
I open months ago a separate thread
http://forum.enjoysudoku.com/17clues-v7-scan-18-clues-scan-t40329.htmlto give more details on this package. After a long silence, I intended to come back in the next weeks with a summary of the changes in progress.
Out of Mathimagics's project, the source could be modified easily to produce some 18s having specific properties, as for example a distribution in box 222222222, something on which works our friend coloin.