# Message #632

From: rev_16_4 <rev_16_4@yahoo.com>

Subject: [MC4D] Re: Parity on MC m^n

Date: Sun, 01 Feb 2009 23:02:23 -0000

I was looking at another site. This gives a similar insight to my

position on parity, and the whole even/odd issue.

http://www.ryanheise.com/cube/parity.html

My n^d solution is entirely composed of conjugates and commutators,

with the odd single quarter twist thrown in for parity. What I meant

to say before was "There are no positions that cannot be solved with

just conjugates and commutators on a n^d, with d>3 and even n. This

is not the case with all other n^d." These other cases are parity

errors, in my opinion.

The first statement implies that on a n^d, with d>3 and even n, you

can solve any position with an even number of quarter twists. This

implies that a single quarter twist can be solved with an even number

of twists. This implies that any position can be solved with an even

or odd number of twists. This logic sounds awefully circular…

On a side note, I think most people when they develop their first

solution to the 3^3, and get to the bottom layer realize the need for

a quarter twist. This puts the problem back in a corners then edges

situation. However I think people have more of a disconnect with the

4^3’s extra layer’s required quarter twist. I think at the point you

realize you need it you have so much of the rest of the puzzle

solved, you don’t want to perform this twist and have to redo it all.

This is where the need for solving parity comes in.

-Levi

— In 4D_Cubing@yahoogroups.com, Roice Nelson <roice3@…> wrote:

>

> 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

> re-saving 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@…> 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^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 <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

> >> 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 (non-caging) techniques

similar

> >> to a 3^4.

> >>

> >> -Levi

> >>

> >> _._,___

> >>

> >

> >

>