Message #630
From: Roice Nelson <roice3@gmail.com>
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.

The reason for the different move counts in the old/new headers was that
resaving the log file with the new program corrected the move numbers (I
didn’t manually change that part). 
As I’m sure you noticed Levi, the second problem I encountered was not
the example you were looking for since it applied to 2C pieces instead of 3C
ones. Nonetheless, these effects seem legitimate examples of what many
think of as parity problems…
Best,
Roice
On Sun, Feb 1, 2009 at 12:16 PM, Roice Nelson <roice3@gmail.com> 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<http://games.groups.yahoo.com/group/4D_Cubing/files/parity%20error%20logs/>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^3like 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 <rev_16_4@yahoo.com> 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 pairswaps to perform, you will have an even number
>> of edge pairswaps 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 pairswaps
>> will always be accompanied by an odd # of Edge pairswaps 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 pairswaps 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
>> this could occur… SOMEONE PLEASE SEND ME AN EXAMPLE LOG FILE!) If
>> 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 (noncaging) techniques similar
>> to a 3^4.
>>
>> Levi
>>
>> _._,___
>>
>
>