mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
f21d3e4c74
I've only just realised that there's a false-positive bug in the latin.c solver framework. It's designed to solve puzzles in which the solution is a latin square but with some additional constraints provided by the individual puzzle, and so during solving, it runs a mixture of its own standard deduction functions that apply to any latin-square puzzle and extra functions provided by the client puzzle to do deductions based on the extra clues or constraints. But what happens if the _last_ move in the solving process is performed by one of the latin.c built-in methods, and it causes a violation of the client puzzle's extra constraints? Nothing will ever notice, and so the solver will report that the puzzle has a solution when it actually has none. An example is the Group game id 12i:m12b9a1zd9i6d10c3y2l11q4r . This was reported by 'groupsolver -g' as being ambiguous. But if you look at the two 'solutions' reported in the verbose diagnostics, one of them is arrant nonsense: it has no identity element at all, and therefore, it fails associativity all over the place. Actually that puzzle _does_ have a unique solution. This bug has been around for ages, and nobody has reported a problem. For recursive solving, that's not much of a surprise, because it would cause a spurious accusation of ambiguity, so that at generation time some valid puzzles would be wrongly discarded, and you'd never see them. But at non-recursive levels, I can't see a reason why this bug _couldn't_ have led one of the games to present an actually impossible puzzle believing it to be soluble. Possibly this never came up because the other clients of latin.c are more forgiving of this error in some way. For example, they might all be very likely to use their extra clues early in the solving process, so that the requirements are already baked in by the time the final grid square is filled. I don't know! Anyway. The fix is to introduce last-minute client-side validation: whenever the centralised latin_solver thinks it's come up with a filled grid, it should present it to a puzzle-specific validator function and check that it's _really_ a legal solution. This commit does the plumbing for all of that: it introduces the new validator function as one of the many parameters to latin_solver, and arranges to call it in an appropriate way during the solving process. But all the per-puzzle validation functions are empty, for the moment.
This is the README accompanying the source code to Simon Tatham's puzzle collection. The collection's web site is at <https://www.chiark.greenend.org.uk/~sgtatham/puzzles/>. If you've obtained the source code by downloading a .tar.gz archive from the Puzzles web site, you should find several Makefiles in the source code. However, if you've checked the source code out from the Puzzles git repository, you won't find the Makefiles: they're automatically generated by `mkfiles.pl', so run that to create them. The Makefiles include: - `Makefile.am', together with the static `configure.ac', is intended as input to automake. Run `mkauto.sh' to turn these into a configure script and Makefile.in, after which you can then run `./configure' to create an actual Unix Makefile. - `Makefile.vc' should work under MS Visual C++ on Windows. Run 'nmake /f Makefile.vc' in a Visual Studio command prompt. - `Makefile.cyg' should work under Cygwin / MinGW. With appropriate tweaks and setting of TOOLPATH, it should work for both compiling on Windows and cross-compiling on Unix. - `Makefile.osx' should work under Mac OS X, provided the Xcode tools are installed. It builds a single monolithic OS X application capable of running any of the puzzles, or even more than one of them at a time. - `Makefile.wce' should work under MS eMbedded Visual C++ on Windows and the Pocket PC SDK; it builds Pocket PC binaries. Many of these Makefiles build a program called `nullgame' in addition to the actual game binaries. This program doesn't do anything; it's just a template for people to start from when adding a new game to the collection, and it's compiled every time to ensure that it _does_ compile and link successfully (because otherwise it wouldn't be much use as a template). Once it's built, you can run it if you really want to (but it's very boring), and then you should ignore it. DO NOT EDIT THE MAKEFILES DIRECTLY, if you plan to send any changes back to the maintainer. The makefiles are generated automatically by the Perl script `mkfiles.pl' from the file `Recipe' and the various .R files. If you need to change the makefiles as part of a patch, you should change Recipe, *.R, and/or mkfiles.pl. The manual is provided in Windows Help format for the Windows build; in text format for anyone who needs it; and in HTML for the Mac OS X application and for the web site. It is generated from a Halibut source file (puzzles.but), which is the preferred form for modification. To generate the manual in other formats, rebuild it, or learn about Halibut, visit the Halibut website at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.