~ubuntu-branches/ubuntu/saucy/sgt-puzzles/saucy

« back to all changes in this revision

Viewing changes to lightup.c

  • Committer: Package Import Robot
  • Author(s): Ben Hutchings
  • Date: 2012-04-07 02:38:40 UTC
  • mfrom: (1.1.15) (3.1.16 sid)
  • Revision ID: package-import@ubuntu.com-20120407023840-1sazcea7ic2k0ano
Tags: 9411-1
* New upstream version - closes: #666709
  - Adds Pearl puzzle
* Update German translation, thanks to Helge Kreutzmann

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
1
/*
2
2
 * lightup.c: Implementation of the Nikoli game 'Light Up'.
 
3
 *
 
4
 * Possible future solver enhancements:
 
5
 *
 
6
 *  - In a situation where two clues are diagonally adjacent, you can
 
7
 *    deduce bounds on the number of lights shared between them. For
 
8
 *    instance, suppose a 3 clue is diagonally adjacent to a 1 clue:
 
9
 *    of the two squares adjacent to both clues, at least one must be
 
10
 *    a light (or the 3 would be unsatisfiable) and yet at most one
 
11
 *    must be a light (or the 1 would be overcommitted), so in fact
 
12
 *    _exactly_ one must be a light, and hence the other two squares
 
13
 *    adjacent to the 3 must also be lights and the other two adjacent
 
14
 *    to the 1 must not. Likewise if the 3 is replaced with a 2 but
 
15
 *    one of its other two squares is known not to be a light, and so
 
16
 *    on.
 
17
 *
 
18
 *  - In a situation where two clues are orthogonally separated (not
 
19
 *    necessarily directly adjacent), you may be able to deduce
 
20
 *    something about the squares that align with each other. For
 
21
 *    instance, suppose two clues are vertically adjacent. Consider
 
22
 *    the pair of squares A,B horizontally adjacent to the top clue,
 
23
 *    and the pair C,D horizontally adjacent to the bottom clue.
 
24
 *    Assuming no intervening obstacles, A and C align with each other
 
25
 *    and hence at most one of them can be a light, and B and D
 
26
 *    likewise, so we must have at most two lights between the four
 
27
 *    squares. So if the clues indicate that there are at _least_ two
 
28
 *    lights in those four squares because the top clue requires at
 
29
 *    least one of AB to be a light and the bottom one requires at
 
30
 *    least one of CD, then we can in fact deduce that there are
 
31
 *    _exactly_ two lights between the four squares, and fill in the
 
32
 *    other squares adjacent to each clue accordingly. For instance,
 
33
 *    if both clues are 3s, then we instantly deduce that all four of
 
34
 *    the squares _vertically_ adjacent to the two clues must be
 
35
 *    lights. (For that to happen, of course, there'd also have to be
 
36
 *    a black square in between the clues, so the two inner lights
 
37
 *    don't light each other.)
 
38
 *
 
39
 *  - I haven't thought it through carefully, but there's always the
 
40
 *    possibility that both of the above deductions are special cases
 
41
 *    of some more general pattern which can be made computationally
 
42
 *    feasible...
3
43
 */
4
44
 
5
45
#include <stdio.h>
215
255
    if (*string == 's') {
216
256
        string++;
217
257
        EATNUM(params->symm);
 
258
    } else {
 
259
        /* cope with user input such as '18x10' by ensuring symmetry
 
260
         * is not selected by default to be incompatible with dimensions */
 
261
        if (params->symm == SYMM_ROT4 && params->w != params->h)
 
262
            params->symm = SYMM_ROT2;
218
263
    }
219
264
    params->difficulty = 0;
220
265
    /* cope with old params */
1672
1717
    /* That didn't work; try solving from the clean puzzle. */
1673
1718
    solved = dup_game(state);
1674
1719
    if (dosolve(solved, sflags, NULL) > 0) goto solved;
1675
 
    *error = "Puzzle is not self-consistent.";
 
1720
    *error = "Unable to find a solution to this puzzle.";
1676
1721
    goto done;
1677
1722
 
1678
1723
solved: