Message #1247

From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Parity in 12 Colors
Date: Thu, 04 Nov 2010 14:01:30 -0700

Andrey,

Performing opposite twists instead of using undo shouldn’t count against
move totals. In MC4D I detect those and turn them into undos for just
that reason. It may seem slightly odd that users can’t undo such moves
but I don’t know that anyone even noticed that. I’d really like to take
that to it’s ultimate extreme and prune out any move sequences that loop
back to any previous state, regardless of the number of moves involved.
With the exception of returning to the solved state of course. :-) At
the very least I think that an option to do this sort of pruning should
be available when saving to a log file, or even as a post-process on
those log files.

Regarding your math, I was rather surprised to learn that you use
Complex arithmetic. I’ve never really understood why they are so useful
in a number of sciences. What do you use them for?

Thanks for another wonderful puzzle, and congratulations on another
amazing first solve,
-Melinda

On 11/1/2010 10:51 AM, Andrey wrote:
> When I almost solved 12 Colors puzzle I found unexpected parity problem: one 3C piece had wrong orientation (transposition) and two 4Cs were swapped. I’ve never seen anything like that before (close situation is on 4^3, but there is transposition of 2Cs instead of flipping, so it’s different). Closer inspection shown that the problem is in the number of 3Cs in one cell: it’s odd (27). So 60-deg rotation had chance to flip orientation of odd number of 3Cs. On other hand, this rotation gives even permutation of 2Cs (6+2+1 cycles), and parity error can’t be detected on the first stage.
> This problem took about 500 extra twists, and puzzle was solved… in 4196 twists (no macros!) and 12h 00m 00s.345 (by timer) :) A little long - but I’m not sure in Undo/Redo operations and used to make back twist instead of Ctrl-Z.
> My solving method is close to speedsolving 3^4 algorithm - it uses the fact that there are two cells with no common pieces. So for 8Color and 14Color this method doesn’t work.
>
> It looks like 1.0 version will be not very soon :( - mathematics in MHT is very complicated (mixed Complex-Modular arithmetics) and some hidden bugs may remain hidden for a long time :(