Archived Thread

------=_Part_52844_20568439.1189296941974
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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
trimmed."

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,

Roice

------=_Part_52844_20568439.1189296941974
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 trimmed."

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.

------=_NextPart_000_0016_01C7F2CD.4AFBEC70
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Congratulation Roice!

Nice work. Another Barrier Broken. (After barrier 100 twists in 2^4, now 30=
0 twists in 3^4. I have to try to break 1000 in 4^4 and 2500 in 5^4 :-)

Enjoy your leadership :-) but be sure I will give a try very soon :-)

Take care,

RemiQ
------=_NextPart_000_0016_01C7F2CD.4AFBEC70
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

w3c.org/TR/1999/REC-html401-19991224/loose.dtd">

>

Thread: "a few thoughts on "post processing" solutions to make them shorter"