Message #4075

From: Marc Ringuette <>
Subject: ROIL Zero explanation, was Re: [MC4D] correction and question
Date: Sat, 28 Jul 2018 10:15:40 -0700

On 7/28/2018 3:06 AM, ‘Eduard Baumann’ [4D_Cubing]
> Question to Marc: what is R[U] exactly in the names of the macro’s?

Hi, Ed!   I explain this in my videos, but I should write it down too.  
Here it is.

In my ROIL Zero macros,

  R [ U ]  ==   on the R cube, make a U move (leaving a side-effect on
the buffer)
               ==   Rz2 Ix’ Rz2

and similarly for the other R [ DLRFB ] using the same buffer, namely,
the four In+Left pieces.   This is similar to the historical RKT solving
style for MC4D.

If you perform any sequence of R []  such that the sum of the clockwise
quarter-twists adds up to 0 mod 4, then the buffer will emerge
unchanged.  For instance,

   Sune on R  ==  R [ R U R’ U R U2 R’ ] == a rearrangement of the U
face of the R cube leaving no side-effects elsewhere.

These macros allow MC4D to follow along with a physical 2x2x2x2 solution
that is done in my convenient ROIL Zero style, that allows the solver to
perform 3D algorithms on any of the R, L, I, or O subcubes of the
physical puzzle, performing a sequence of (individually
parity-violating) 4-cycles, AS LONG AS the sum of the turns adds up to 0
mod 4 when the puzzle halves are reattached.

Nobody but me has used the ROIL Zero style yet, except for "Can Chris
Solve", who did something almost identical in his followup video where
he reconciles his use of 3D algorithms with the requirements of
permutation parity on the MC4D 2^4 puzzle.   I’ve cued it up here:

A few other solvers have simply ignored permutation parity, as I did a
year ago until it was brought to my attention.  Ignoring parity –
freely using 4-cycle twists without counting parity at all – is even
more convenient, and internally consistent, but solves a slightly
different puzzle than our gold standard of MC4D.    Doing so leads to a
situation where the physical puzzle can spend a long time in an odd
permutation parity state that cannot be duplicated by MC4D at all.  
Maybe this is fine for you!   I, and Chris, decided to split the
difference.   We retained our really convenient shorthand for performing
3D algorithms on the physical puzzle, while doing enough housekeeping to
ensure that the physical puzzle and MC4D are always in compatible states
when the subcubes are reattached at the end of each algorithm.  By
providing these macros, I’m making our approach as kosher as possible,
by providing an explicit way to translate any carefully executed ROIL
Zero solution into a canonical one.