diff options
| author | Simon Tatham <anakin@pobox.com> | 2016-02-24 19:22:57 +0000 |
|---|---|---|
| committer | Simon Tatham <anakin@pobox.com> | 2016-02-24 19:22:57 +0000 |
| commit | 24848706edfdd1db1f97e3681d7ff52bec2fa575 (patch) | |
| tree | f2b0024fe8604fb0ef4cfd3a9440e776c2d6c691 /html/pattern.html | |
| parent | 755c3d5277262739e8beb03da3649e7f4d53e915 (diff) | |
| download | puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.zip puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.tar.gz puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.tar.bz2 puzzles-24848706edfdd1db1f97e3681d7ff52bec2fa575.tar.xz | |
Loopy: revamp loop detection, but not using findloop.
Loopy differs from the other recently-reworked puzzles in that it
doesn't disallow loops completely in the solution - indeed, one is
actually required! But not all loops are what you wanted, so you have
to be a bit more subtle in what you highlight as an error. And the new
findloop system doesn't make that easy, because it only answers the
question 'is this edge part of a loop?' and doesn't talk about loops
as a whole, or enumerate them.
But since I was working in this area anyway, I thought I might as well
have a think about it; and I've come up with a strategy that seems
quite sensible to me, which I describe in a big comment added in
loopy.c. In particular, the new strategy should make a more sensible
decision about whether to highlight the loop or the non-loop edges, in
cases where the user has managed to enter a loop plus some extra
stuff.
Diffstat (limited to 'html/pattern.html')
0 files changed, 0 insertions, 0 deletions