simon-git: puzzles (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  5030d87 latin_solver_alloc: handle clashing numbers in input grid.
  05c536e Pearl: fix assertion failure on bad puzzle.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2023-02-05 11:39:21

commit 5030d87903191d581586ecda2382ad5bcd70f63d
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=5030d87903191d581586ecda2382ad5bcd70f63d;hp=517b14e666b0b71fc0bcd5da1b22cdc90d3434c9
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 5 10:29:42 2023 +0000

    latin_solver_alloc: handle clashing numbers in input grid.
    
    In the setup phase of the centralised latin.c solver, we start by
    going over the input grid containing already-placed clue numbers, and
    calling latin_solver_place to enter each on into the solver's data
    structure. This has the side effect of ruling out each number from the
    rest of the row and column, and _also_ checking by assertion that the
    number being placed is not ruled out.
    
    Those are a bad combination, because it means that if you give an
    obviously inconsistent input grid to latin_solver_alloc (e.g. with two
    identical numbers in a row already), it will fail an assertion. In
    that situation, you want the solver run as a whole to return
    diff_impossible so that the error is reported cleanly.
    
    This assertion failure could be provoked by giving either Towers or
    Group a manually-constructed game description inconsistent in that
    way, and hitting Solve. Worse, it could be provoked during live play
    in Unequal, by filling in a number clashing with a clue and then
    pressing 'h' to get hints.

 latin.c            | 47 ++++++++++++++++++++++++++++++-----------------
 latin.h            |  9 ++++++---
 unequal.c          | 30 ++++++++++++++++--------------
 unfinished/group.c | 15 ++++++++-------
 4 files changed, 60 insertions(+), 41 deletions(-)

commit 05c536e50d0c3114e1de5283eac97ff22bad0fc7
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=05c536e50d0c3114e1de5283eac97ff22bad0fc7;hp=5030d87903191d581586ecda2382ad5bcd70f63d
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 5 11:19:30 2023 +0000

    Pearl: fix assertion failure on bad puzzle.
    
    Similarly to the previous commit, if you started Pearl with at least
    some kinds of invalid puzzle (e.g. "6x6:abBfWcWWrBa") and then pressed
    'h' to get hints, you could provoke an assertion failure. But this
    time the assertion wasn't in the solver itself; the solver gave up
    gracefully and didn't crash, but it _did_ leave the links between
    squares in the game_state in an inconsistent state, in that one square
    was marked as linking to its neighbour without the neighbour also
    linking back to it. This caused the /* should have reciprocal link */
    assertion in dsf_update_completion to fail, when that was called from
    check_completion after the solver had finished, to decide whether the
    puzzle was now solved.
    
    In this commit, I arrange that whether or not pearl_solve returns a
    grid layout that's legal by the rules of the _puzzle_, it at least
    returns one that's legal by the rules of the _data representation_, in
    that every link between squares is either bidirectional or absent.
    
    This is a better solution than just removing the assertion, because if
    the inconsistent data were allowed to persist, it would lead to
    further problems in gameplay. For example, if you just remove that
    assertion instead of this fix and press 'h' on the example puzzle id
    above, you'll find that the non-reciprocal links are actually visible,
    in the form of several thick lines that stop at a grid square boundary
    instead of connecting two square-centres. (It looks even sillier if
    you set PEARL_GUI_LOOPY=y.)
    
    That's a situation that can't be created by a normal move, and if you
    try to make normal moves after it (e.g. click one of the weird edges),
    you'll find that both sides of the half-link get toggled, so now it's
    a half-link the other way round. So not only can't you _create_ this
    situation in normal play, you can't get rid of it either!
    
    That assertion in dsf_update_completion was commented out at one
    point, and I put it back in commit c5500926bf7458a saying that if it
    failed I'd like to know about it. And indeed, I'm glad I did, because
    this kind of unfixable wrongness in the resulting game_state was worth
    noticing and getting rid of!

 pearl.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)