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
> >>
> >> _._,___
> >>
> >
> >
>