Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add code to generate supernecklaces and -bracelets #14

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

pozorvlak
Copy link
Contributor

A necklace is an equivalence class of strings under rotation; a bracelet is an equivalence class of strings under rotation and reflection. Restricting our attention further to necklaces/bracelets without
repetitions, we can search for "supernecklaces" and "superbracelets", which are strings that contain some representative of each non-repeating necklace/bracelet as a substring (equivalently, strings
which, for every permutation p, contain a substring that may be rotated and/or reflected to obtain p).

This is not a classic TSP, but it can be framed as an Equality-Generalised Travelling Salesman Problem, which can then be converted into an ATSP and solved by the GLKH solver, http://webhotel4.ruc.dk/~keld/research/GLKH/.

This work was inspired by Matthew Clarke's questions on the forum: https://groups.google.com/forum/?#!msg/superpermutators/H1_jrq_EO1c/unrp4Gl_GQAJ

I don't think this is quite ready to be merged: I'd like to make it a bit easier to actually run the solver first (I had to hack up the supplied runGLKH script).

A necklace is an equivalence class of strings under rotation; a bracelet
is an equivalence class of strings under rotation and reflection.
Restricting our attention further to necklaces/bracelets without
repetitions, we can search for "supernecklaces" and "superbracelets",
which are strings that contain some representative of each
non-repeating necklace/bracelet as a substring (equivalently, strings
which, for every permutation p, contain a substring that may be rotated
and/or reflected to obtain p).

This is not a classic TSP, but it can be framed as an
Equality-Generalised Travelling Salesman Problem, which can then be
converted into an ATSP and solved by the GLKH solver,
http://webhotel4.ruc.dk/~keld/research/GLKH/.

This work was inspired by Matthew Clarke's questions on the forum:
https://groups.google.com/forum/?#!msg/superpermutators/H1_jrq_EO1c/unrp4Gl_GQAJ
@pozorvlak
Copy link
Contributor Author

pozorvlak commented Feb 17, 2019

More seriously, it's not finding the shortest supernecklace for n = 3: I'm getting 123213, but unless I'm missing something then 12321 should do. Here's my input file:

NAME: supernecklace 3
TYPE: GTSP
DIMENSION : 6
EDGE_WEIGHT_TYPE : EXPLICIT
EDGE_WEIGHT_FORMAT : FULL_MATRIX
NODE_COORD_TYPE : NO_COORDS
DISPLAY_DATA_TYPE : NO_DISPLAY
EDGE_WEIGHT_SECTION :
0 3 3 1 2 2
0 0 2 2 3 1
0 1 0 3 2 2
0 2 3 0 1 3
0 3 2 2 0 3
0 2 1 3 3 0
GTSP_SETS: 2
GTSP_SET_SECTION
1 1 4 5 -1
2 2 3 6 -1
EOF

and here's the output file:

NAME : supernecklace.0.tour
COMMENT : Length = 0
COMMENT : Found by GLKH [Keld Helsgaun] Sun Feb 17 22:15:58 2019
TYPE : TOUR
DIMENSION : 2
TOUR_SECTION
1
3
-1
EOF

and here's the .par file I used (generated by the runGLKH script that came with GLKH):

PROBLEM_FILE = gtsp/necklace_3.gtsp
ASCENT_CANDIDATES = 500
INITIAL_PERIOD = 1000
MAX_CANDIDATES = 30
MAX_TRIALS = 1000
OUTPUT_TOUR_FILE = gtsp/necklace_3.gtsp.$.tour
PI_FILE = PI_FILES/gtsp/necklace_3.gtsp.pi
POPULATION_SIZE = 1
PRECISION = 10
RUNS = 1
SEED = 1
TRACE_LEVEL = 1

Am I doing something obviously wrong? I couldn't immediately find a spec for the .gtsp format, so I reverse-engineered it from the supplied examples. Am I right in thinking that LKH isn't guaranteed to find the shortest possible tour? Even so, I'd expect it to do so on such a small example.

@pozorvlak
Copy link
Contributor Author

I also wrote some much more naive code for this problem in the constraint-solving language MiniZinc: it's vastly slower than this, but does at least get the right answer for the n = 3 supernecklace. Would it be welcome in this repository?

Input files that specify `TYPE: GTSP` are assumed to be symmetric by
GLKH. Input files for asymmetric GTSPs must have `TYPE: AGTSP`. This
change makes GLKH produce optimal supernecklaces for n = 3 and 4, and
substantially improves the lengths of the supernecklaces and -bracelets
found for n \in {5, 6, 7}.
@robinhouston
Copy link
Contributor

I won’t lie: the most exciting thing about this for me is that I have learnt about GitHub’s new “draft pull request” feature! :-)

@robinhouston
Copy link
Contributor

@pozorvlak The MiniZinc code would be very welcome, yes! We are language-agnostic here. :-)

@pozorvlak
Copy link
Contributor Author

I fixed the problem with finding overlong supernecklaces, by the way: GLKH was interpreting my input files as containing undirected graphs. The two-character fix is in d9de7cc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants