SudokuSolver Forum

Besides the well known PS code from djape, Ruud has also designed a very presentable text format. Here is an example puzzle from tarek at sudoku.com:

tarek gave a very thoughtful arrow-based text representation himself as well:

Code:
 v < 16| <20 7 | < 6 <
17 > > |22 ^ 26| < < ^
10 ^ > | 6 ^ 21| < ^13
-------+-------+------
 ^ ^ ^ |42 > v | ^ ^ ^
11 < < | ^ 3 v | > >18
10 v v | ^ < < |16 v 9
-------+-------+------
 ^ v > |12 19> | ^ v ^
17 > > |31 ^ 23| < <14
 ^ < 9 | < ^ 7 | < > ^

You just need to follow the arrows to know a cell belongs to which cage.

I've made some changes myself, and came up with this 162-char representation:

Code:
17 <16 <20 7 < 6 <
 ^22 < < ^26 < < ^
10 ^ 6 < ^21 < ^13
 ^ ^ ^42 < < ^ ^ ^
11 < < ^ 3 ^18 < <
103112 ^ < ^1623 9
 ^ ^ ^ <19 > ^ ^ ^
17 ^ < < ^ > > ^14
 ^ < 9 < ^ 7 < > ^

These 2 rules are added:

1. All cage sums must appear in the leftmost cell of the topmost row of that cage.
2. When choosing arrows we always uses the order of preference: ^ < > v.

When there are "diagonal cages". I suggest we use the 4 symbols: ` ' , . to represent UL,UR,DL,DR arrows respectively, in that order of preference.

And if we use A..Z to represent 10..35, a..j to represent 36..45, we can have an 81-char representation:

Of course it's not as attractive as Ruud's code but wouldn't it be cool if we can always use an 81-char string to represent all killer puzzles?

_________________
ADYFNC HJPLI BVSM GgK Oa m

Nice!

Unfortunately it doesn't give the flexibility for remote or diagonal cages - I gues you could use a \ / for diagonals, but still leaves the problem of remotes.

You could get to an 81 char string if we used a wider range of ASCII codes. Perhaps use a single range of 46 characters to represent the cage value - located in the top/left cell (as per your A-Z, a-j)

Then use a seperate group of 81 (or less) character codes for the other cells either to point to the topleft cell for the cage for that cell or to point to the cage number. This is analogous to the way the Sumocue format works for Killer.

` is for UL=up-left
' is for UR=up-right
, is for DL=down-left
. is for DR=down-right
I guess one can use / for UR and \ for DR, but it's a bit ambiguous.

I never think much about remote cages. It's just not elegant puzzle designing. Don't think it'd ever be very popular among players either.


You don't have that many displayable ASCII chars though. (The way I see it you need a range of about 46+81=127 different chars to cater for the remote cages.) The whole point is to make a format which is compact and not too difficult for the user to manually convert.

For example, you have 100 assassins in the database, all of which probably don't have remote cages. Using this 81-char format and then maybe an extra char to denote if it's an X or not, you can store the whole collection in 100 lines of 82 chars. That probably is more handy than 100 pics or 100 of those very long PS codes. And the advantage is even bigger if you have 1000 or 10000 puzzles.

_________________
ADYFNC HJPLI BVSM GgK Oa m

This clashes (or at least is ambiguous) since 'V' means both "down arrow" and "31"...

_________________
Jean-Christophe
"When you have eliminated the impossible, whatever remains, however improbable, must be the truth." Sherlock Holmes.

Tsk tsk tsk... JC, I thought you're more observant than that. Should be able to distinguish between captial letters and small letters.

Note I reserve the small letters k..z for special properties (e.g. diagonal, windoku, NC, repeat cages). Or if one doesn't like the 4 punctuation symbols as diagonal arrows we can use 4 of those small letters (e.g. k,l,m,n) to represent them.

_________________
ADYFNC HJPLI BVSM GgK Oa m

Sure, it's easy for a program to distinguish the lower and upper case 'v'. But for a human, they can be easilly confused. That's why I said "or at least is ambiguous".

As it is now, since it has 81 characters, it would be hard for a program to distinguish vanilla sudoku and this format. In particular since the format does not contains any "sure" sequence of unique characters.

So I would suggest to start the line with some identifier to make it much easier for a program to detect this format. That's what Ruud uses in SumoCue for Jigsaw (vanilla or killer), which line starts with "SumoCueV1". DJApe format is also easy to detect by looking at the sequence ":k:" in the first characters.

This identifier could also be followed by some attributes for diagonal, non-cons... Ruud uses 'D' for diagonal jigsaw.

Then using some separator beween the header and the data. For example ':'.

Extension: '0' for zero cages. When exporting, if no cage for a cell, make it it a single cell zero cage. When importing, zap single cell zero cages.

_________________
Jean-Christophe
"When you have eliminated the impossible, whatever remains, however improbable, must be the truth." Sherlock Holmes.

Yep, all these attributes make sense, and many of them I've discussed elsewhere too.

_________________
ADYFNC HJPLI BVSM GgK Oa m

if we're definig cage sum in the top left cell, do we need v ? we should only need to refer to a cell that is to the left or above, or if a cage starts in column 9, possibly to the right

When I suggested \ / for diagonals, we only need to point either to the above left and above right cells.

as far as the header is concerned, the colon as a separator is fine. As JC mentions, why not something like:

a grid sizing marker - 3x3: 2x4: etc
variant attributes:
k: (currently PS killer - we would need another letter for a "compact" killer definition)
d: diagonal

how about
nc: nnc: fnc: etc for non-con
j: for jigsaw
w: for windoku

I think we need all directions because of cages where the top cell (where the cage sum is displayed) is not the most left cell. For example, cages that are shaped like inverted T's or that have a zigzag-shape (for example A106: 26(5) cage @ N5). Or just look at the 42(8) cage @ N5 from udosuk's example where all arrows are used.

Like Richard said, we still have the problem with remote cages which are sometimes used in variants. Another problem would be cells that belong to multiple cages like in Human Solvable One (R5C5 belongs to two cages). So we have to decide if we consider all variants of if we leave some of them off.

If we want to include all those variants, then an idea would be to use characters for cages and every cell gets one or more characters and afterwards we define which characters has what sum (I got this idea from another sudoku forum).

For the example it would be:

a a b b c d d e e
a f f f c g g g e
h f i i c j j g k
h f i l l l j g k
m m m l 3 l n n n
o p q l l l r s t
o p q q u r r s t
v p p p u s s s w
v v x x u y y w w

and then 17, 16, ... , 9, 7 to define the cage sums. For cells with multiple cages, we could use :AB:.

Note that one cell cages get directly defined by their numbers since we don't want to use to much characters (a-z, A-Z and 1-9 for one-cell cages and 0 for non-cage cells). The type of the Killer would get defined like in the PS code.

The problem with that is that it's not the shortest way to describe the Killer in a string but it's easy to understand for programms and humans.
I'll post the full code, it would have, later (gotta go to university ).

I would expect that the cages always had the value in the topmost cell, regardless of it it was leftmost - i.e. moving from cell 1 to cell 81, you define the cage value at the first cell. By definition, then, no cage cell can be "above" the cell with the cage definition in it.

an inverted T would be: