Message #630

From: Roice Nelson <>
Subject: Re: [MC4D] Re: Parity on MC m^n
Date: Sun, 01 Feb 2009 14:43:32 -0600

Sorry, just reread this after going to lunch with a friend and saw a couple
things I wanted to clarify/correct.


On Sun, Feb 1, 2009 at 12:16 PM, Roice Nelson <> wrote:

> I dug up old cd backups I had and found my log files from April 2000! I
> save solutions along the way out of paranoia, and luckily I had files at the
> problem points I saw. I just uploaded 2 log files to the a new folder in
> the files area of the group<>showing the parity error situations I encountered on my 4^4 solution.
> quick aside on a program technical issue: These weren’t loading with the
> current java version (back then the 4^4 was only available in the linux
> version). I altered the header line to look more current, and they seems to
> load fine now. However, since I don’t know the format, I’m unsure of what
> ramifications the editing might have. Here is an example.
> old: MagicCube4D 1 0 857
> new: MagicCube4D 2 2 844 4
> Anyway, I’ll do my best now to reconstruct what looks like was going on - I
> can’t remember last week, much less the details of a decade ago :)
> In the first file, I was trying to solve 2C pieces. When matching up sets
> of four, I found the very final set (orange/yellow) had two in one
> orientation and two in another, as in the puzzle state of the log file.
> This is not a parity problem in the context of a reduction to a 3^4 since
> the reduction hasn’t even happened yet. Rather it is a parity problem in
> the context of a 4^3! Because when pairing up the 2Cs on a 4^3, you will
> never encounter the situation where all are matched up to form single
> 3^3-like edges except that the last two are flipped in relation to each
> other. If placed on the same edge, the final two will always be in the same
> orientation. I’m glad I pulled this out again, because this feels more
> subtle that what I had written in my last email. In essence, the problem is
> the same however. I saw an "impossible" configuration when using a simpler
> mental model of parities on a more complicated puzzle. I hope this made
> sense because it is a really interesting effect to me.
> In the second file, the situation is a parity problem in the context of a
> 3^4 reduction, again relative to 2C pieces. The final (pink/red) 2C was
> flipped as a whole, so I believe this is the case you wanted to see an
> example of. Unfortunately, the log file doesn’t easily show how to generate
> this position from a pristine state. Indeed, the possibility of it may rely
> on the permutations/orientations of 3C pieces, so it may not be possible
> without scrambled 3C pieces?
> Let me know what you think!
> Roice
> On Sun, Feb 1, 2009 at 1:20 AM, rev_16_4 <> wrote:
>> Roice, you bring up a very good point. I wasn’t sure there were
>> positions on a 4^d that, using a reduction method, would generate
>> impossible positions on a 3^d (I’m going to switch to your notation,
>> it’s been around longer). I thought it might be possible, seeing that
>> was the gereral consensus. But I hadn’t experienced one myself. Can
>> someone email me a 4^4 log file with such a position?
>> I’m still retaining my nontraditional definition of parity errors
>> essentially as odd parity (and in my n^d solution double odd as
>> well). Ignoring this definition, check out the "single flipped"
>> parity error on a 4^3. It will take an odd number of inner slice
>> quarter twists to solve this.
>> On a 3^3, a single swapped pair has odd parity. This cannot happen
>> due to the even (aka double odd) parity of a single quarter twist on
>> a 3^3. However, using reduction, the "single swapped edge pair" (with
>> correct orientation) parity err on a 4^3 can seem to occur. This will
>> alway take an even number of quarter twists to solve.
>> You can see a similar phenomenon with a 3^3. If you have an even
>> number of corner pair-swaps to perform, you will have an even number
>> of edge pair-swaps also. It took an even number of quarter twists to
>> generate this position, and it will take an even number of quarter
>> twists to solve. The same goes for odd. An odd # of Corner pair-swaps
>> will always be accompanied by an odd # of Edge pair-swaps and an odd
>> # of twists. This is my double odd parity.
>> Now with the case of n=4, d>3, this rule above is not the case. you
>> can generate any position with an even number of twists, or an odd
>> number of twist. I’d write out all the actual pair-swaps from a
>> single quarter twist, but I’m too lazy right now. In a nutshell there
>> are 6 corner pairs, 18 edge pairs, 18 face pairs, and 6 center pairs
>> swapped during an outer slice rotation. An inner slice rotation has 6
>> edge pairs, 18 face pairs, and 18 center pairs swapped. As you can
>> see, all are even, hence even parity (the faces and centers are
>> irrelevent). You can never generate an odd parity position, hence my
>> belief there are no parity errors for this puzzle.
>> With the reduction method, sometimes the pairs are swapped in such a
>> manner that a simple even parity position for the caging method I
>> use, if attempted to be solved using reduction, would result in an
>> unsolvable 3^4 position. (I’m trying to think of a position where
>> someone can show me a log with a "single 3C w/ two stickers flipped"
>> 4^4 parity position, and how to generate it, I’d be grateful (and
>> completely shocked!). Other than that, I can’t think of a 4^4 parity
>> that I think would be unsolvable with (non-caging) techniques similar
>> to a 3^4.
>> -Levi
>> _._,___