# Message #1236

From: Roice Nelson <roice3@gmail.com>

Subject: Re: [MC4D] Parity in 12 Colors

Date: Mon, 01 Nov 2010 14:24:01 -0500

Cool, nicely done :) I played around with the 12 colors puzzle some this

weekend too, but am only at the point of finishing up the 2C pieces, and my

timer is about to hit 2 hours (I currently have all 2Cs solved but two,

which are positioned but flipped - possibly a parity problem, not sure). I

bet my timer will read much higher than 12 hours if I ever go the entire way

- I spend too much time tripping out on the visualization :D

I found the way this puzzle is connected up beautiful, of course. One

property is that it is reminiscent of 2D Klein’s Quartic puzzle, with "two

bottoms". Each cell has two cells that are not adjacent to it and

unaffected by its twists. And if you pick a cell and start solving outward

from there, as I was in my approach, you end up with two disjoint, unsolved

cells at the end. This is what happened with me for the 2C pieces.

Also, certain sets of 6 cells makes a ring, each ring containing two of

these groups of 3 "opposite" cells. Two disjoint rings can account for the

12 colors of the puzzle, slightly reminiscent of the {6}x{6} duoprism. It’s

different though, because you can mentally select the two disjoint rings in

many different ways, whereas on the duoprism there is only one way to do so.

Roice

On Mon, Nov 1, 2010 at 12:51 PM, Andrey <andreyastrelin@yahoo.com> 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 :(

>

> Good luck!

> Andrey

>

>

>

> ————————————

>

> Yahoo! Groups Links

>

>

>

>