Message #420

From: Roice Nelson <>
Subject: a few thoughts on "post processing" solutions to make them shorter
Date: Sat, 08 Sep 2007 19:15:41 -0500

I haven’t yet looked at the moves in my last logfile for extraneous twists
as Remi had done. Seems there could be a couple of "post processing"
optimizations one could do.

One check would be to look for multiple sequential moves on a single face
that could be combined into one. This may be what Remi was looking for as
he went through twist by twist?
Another check would be to catch preliminary moves that effectively countered
preliminary moves from previous sequences, resulting in duplicate puzzle
states. This would be hard for a human to spot using the log files, but…
this is something a computer would be very good at. It could check the
state after each move and store it and the associated move number in a
container (e.g. a list or hashtable). As it ran through the moves, if it
ever found a puzzle state that already existed in the list, it could remove
all the unnecessary twists which had only served to bring the puzzle back to
a place it already had been. I may take a gander at writing such a function
sometime. Though I don’t think it would make any significant difference in
the length of my latest solution, it would help ensure all "the fat had been

I did notice the new MC4D does a little optimizing along these lines for
you, in that a move which is the reverse of the previous move doesn’t append
the log, and instead removes the previous move. I liked this. I also
noticed the move must by physically the opposite, not logically the opposite
(you need to do a reverse click on the exact same sticker). A state check
function would catch logical cases as well, and be able to catch arbitrarily
long sequences that returned someone to a previous state.

Hope this finds everyone well,