Notation for import/export

For fans of Killer Sudoku, Samurai Sudoku and other variants

Notation for import/export

Postby Hajime » Fri Feb 08, 2019 12:34 pm

The (defacto) standard for transfering (import/export) a puzzle is using a 81-char line like:
000001080020003000003900100200000070001040900080000006005009400000400090070200000
An enumeration of all cells in reading order, where a '0' (or '.') denotes an empty cell.
Also applicable for Gattai puzzles by adding more 81-chars lines.

What is the format for transfering Jigsaw puzzles?
I found an example of Mathimagics:
Code: Select all
4.....7...8.....13.9..5..6..3.1482.......2............5.7.....6..829...4.........
AABBBBBCCDAABBBBCEDAACCCCCEDAFFFCEEEDAAFFFGGEDDDHFFFGEDHHHHHGGEDHIIIIGGEHHIIIIIGG
and the A's, B's, C's etc form a piece of 9 cells. Capital/LowerCase independant?
Is a Jigsaw always replacing the boxes or can they exists together in one puzzle?

And what about "greater-than" puzzles?
Is there a standard way of notation for transfer?
User avatar
Hajime
 
Posts: 97
Joined: 20 April 2018
Location: Netherlands

Re: Notation for import/export

Postby Mathimagics » Fri Feb 08, 2019 1:36 pm

Hajime wrote:Is a Jigsaw always replacing the boxes or can they exists together in one puzzle?

Most people assume a "Sudoku Jigsaw" is a 3D puzzle, namely rows + cols + jigsaw-regions.

But they can certainly exist together - my generator produces 4D Jigsaw puzzles, ie. with rows + cols + boxes + jigsaw-regions.

JSudoku and Broughton's SudokuSolver use "Sumocue" format for import/export of jigsaw puzzles. That combines clues with jigsaw-regions in a rather cumbersome 324 character format, which is twice as long as it needs to be, so I really am not fond of that at all.

My use of A-G in those examples you found can of course be replaced by the standard 1 to 9 format. My generator accepts either form. And whether the puzzle definition is all on one line or two separate lines should not really matter. My "import puzzle from clipboard" function strips all non-significant characters, including NL's and CR's, spaces etc. If what is left has exactly 162 characters it is split into its 2 components (puzzle + jigsaw-definition) and treated accordingly. When posting in this forum it is just neater, more convenient, to split them into two lines.

How to distinguish between a 3D Jigsaw and a 4D Jigsaw? I think a tag is the best option. It also caters for any 4D/5D/6D puzzle. My most exotic creation is a 6D puzzle which has rows + cols + Jigsaw-regions + Sudoku-boxes + SudokuP (aka Disjoint groups) + SudokuW (Windoku). And it also comes with diagonals (SudokuX).

Since it is only the Jigsaw Regions that need explicit identification, a tag system makes sense. A tag identifies the puzzle type, eg "JS", "JSPWX", and is followed by the normal puzzle definition and (if Jigsaw mode), the jigsaw definition.

So for our original example, I would indicate the 4D case (ie Sudoku boxes also apply) like this:
Code: Select all
JS
4.....7...8.....13.9..5..6..3.1482.......2............5.7.....6..829...4.........
AABBBBBCCDAABBBBCEDAACCCCCEDAFFFCEEEDAAFFFGGEDDDHFFFGEDHHHHHGGEDHIIIIGGEHHIIIIIGG
User avatar
Mathimagics
2017 Supporter
 
Posts: 1433
Joined: 27 May 2015
Location: Canberra

Re: Notation for import/export

Postby Mathimagics » Fri Feb 08, 2019 3:05 pm

Hajime wrote:And what about "greater-than" puzzles?
Is there a standard way of notation for transfer?


That's where things get pretty messy, I'm afraid. I've never seen any software that supports Futoshiki / Sudoku Inequality clues (<, >), so there is no standard.


I made a separate generator for these some time back, and it uses 2 additional 81-character puzzle-definition strings, with each string using only characters ".", "<" and ">".

One string for the horizontal clues (H-def), one for vertical clues (V-def). So a "<" in position 11 would indicate that r2c2 < r2c3 in the H-def. In the V-def that would indicate r2c2 < r3c2.
User avatar
Mathimagics
2017 Supporter
 
Posts: 1433
Joined: 27 May 2015
Location: Canberra

Re: Notation for import/export

Postby tarek » Fri Feb 08, 2019 9:19 pm

If there is still interest. I developed with udosuk the 81 character Killer sudoku notation which works in most cases. We were lucky as JC also included it in JSudoku

http://forum.enjoysudoku.com/understandable-snarfable-killer-cages-t6119.html

tarek
User avatar
tarek
 
Posts: 3182
Joined: 05 January 2006

Re: Notation for import/export

Postby Hajime » Mon Feb 11, 2019 9:10 am

Thank you all
I will implement the Jigsaw and Greater-Than puzzles like Mathimagics suggested in a next version of SiSeSuSo.
The tag may be different and be put in a first line.
The Killer notation of tarek is one step too far for me at this moment.

But first things first. I have a deadline for 14-feb.
User avatar
Hajime
 
Posts: 97
Joined: 20 April 2018
Location: Netherlands

Re: Notation for import/export

Postby Mathimagics » Mon Feb 11, 2019 2:41 pm

Hajime wrote:The Killer notation of tarek is one step too far for me at this moment.

tarek is one sick puppy, that's for sure! :lol:

I'm still trying to get my head around "snarfability" ...
User avatar
Mathimagics
2017 Supporter
 
Posts: 1433
Joined: 27 May 2015
Location: Canberra

Re: Notation for import/export

Postby tarek » Mon Feb 11, 2019 10:03 pm

Mathimagics wrote:
Hajime wrote:The Killer notation of tarek is one step too far for me at this moment.

tarek is one sick puppy, that's for sure! :lol:

I'm still trying to get my head around "snarfability" ...
My other option was "Slurp" :lol:
User avatar
tarek
 
Posts: 3182
Joined: 05 January 2006

Re: Notation for import/export

Postby Hajime » Mon Feb 18, 2019 9:01 am

Hajime wrote:
I found an example of Mathimagics:
Code: Select all
4.....7...8.....13.9..5..6..3.1482.......2............5.7.....6..829...4.........
AABBBBBCCDAABBBBCEDAACCCCCEDAFFFCEEEDAAFFFGGEDDDHFFFGEDHHHHHGGEDHIIIIGGEHHIIIIIGG

Is a Jigsaw always replacing the boxes or can they exists together in one puzzle?

During some tests above example WITH 3x3 boxes is pretty straightforward: singles only.
But WITHOUT the 3x3 boxes no known method solves it (except brute-force),
but it leads to the same solution and no other solutions are possible. Curious.
User avatar
Hajime
 
Posts: 97
Joined: 20 April 2018
Location: Netherlands

Re: Notation for import/export

Postby Mathimagics » Mon Feb 18, 2019 9:28 am

A standard Jigsaw Sudoku (SudokuJ) has no box constraints, but it stands to reason that some solution grids for a given Jigsaw layout will have valid Sudoku box patterns satisfied.

When this happens any SudokuJ puzzle on that JL is also a valid puzzle in SudokuJS mode, ie with the box constraints added, but will be harder to solve, whether by computer or human.
User avatar
Mathimagics
2017 Supporter
 
Posts: 1433
Joined: 27 May 2015
Location: Canberra

Re: Notation for import/export

Postby tarek » Mon Feb 18, 2019 9:40 am

Mathimagics wrote:A standard Jigsaw Sudoku (SudokuJ) has no box constraints
The Jigsaw regions are in addition to Latin square constraints ... SudokuJ implies Box & Jigsaw. You may need to explicitly mention what constraints you are using in that case unless you call it something like Latin_SquareJ for instance. The letter "Q" has been used before as a short descriptive of Latin Square. QJ puzzles are therefore IMO best to describe your Regular Jigsaw puzzles.
User avatar
tarek
 
Posts: 3182
Joined: 05 January 2006

Re: Notation for import/export

Postby Mathimagics » Mon Feb 18, 2019 10:11 am

Hi tarek

I'm well aware of this anomaly!

However, in the puzzler world "Jigsaw Sudoku" or "Sudoku Jigsaw" is in common (if not universal) usage, despite the fact that it is not technically a Sudoku.


So, I will stick with SudokuJ for regular "Sudoku Jigsaw", but I will use SudokuJB in future for the Sudoku box constraints variant … how's that?
User avatar
Mathimagics
2017 Supporter
 
Posts: 1433
Joined: 27 May 2015
Location: Canberra

Re: Notation for import/export

Postby tarek » Mon Feb 18, 2019 12:22 pm

Mathimagics wrote:So, I will stick with SudokuJ for regular "Sudoku Jigsaw", but I will use SudokuJB in future for the Sudoku box constraints variant … how's that?
In addition to snarfing and slurping, nit-picking is another puppy oriented activity I do :D.

I guess that due to the popularity of sudoku, we can twist the facts and consider Latin square a variant of sudoku that lacks square regions. It doesn't matter what wording you use as long as it is clear to the solver what to do & as long as I can reference this conversation in the future if confusion arises :D
User avatar
tarek
 
Posts: 3182
Joined: 05 January 2006

Re: Notation for import/export

Postby Mathimagics » Mon Feb 18, 2019 1:25 pm

tarek wrote:In addition to snarfing and slurping, nit-picking is another puppy oriented activity I do


My daughter is a professional pedant - I really have no idea where she gets this ability from! :?

… so a little nit-picking doesn't bother me at all. 8-)

Whether nit-picking actually qualifies as puppy-oriented is another matter entirely …
User avatar
Mathimagics
2017 Supporter
 
Posts: 1433
Joined: 27 May 2015
Location: Canberra


Return to Sudoku variants

cron