Generator Notation

[leeo]

D L2 B2 L2 U B2 U2 B' R' U2 F2 U2 B' L D' F2 L D L2
BLD reading: dpsv: (KNXW_IPOQE_Fl_Bm_#_DEt+p_BKXLO_Ci-h)

the letter system is Speffz. the first four letters "dpsv:" refer to the new orientation where the centers of each face points after the scramble. "d" is a Speffz specification for the UL edge, and the upper side center of the U face, originally pointing to the UB (12:00 position) now points to Speffz "d", or UL (9:00 position). This is useful for determining if an algorithm is "supercube safe". If there is no reorientation of the centers, there will be no prefix in this form.

"(KNXW_IPOQE_Fl_Bm_" is the edge orientation. The solution presented appears to prefer the edge buffer FD or Speffz K_ which contains the cubie that goes at N_ which contains the cubie that goes at (wctctga) X_ wctctga W_ wctctga K_ back to where we started. The next preferred edge appears to be FU or Speffz I_ wctctga P_ wctctga O_ wctctga Q_ wctctga E_ back to where we started. Fl_ is notation that the FL cubie at Speffz F_ is flipped in place to LF or Speffz L_. Similaly for the UR cubie at Bm_.

"#_DEt+p_BKXLO_Ci-h" is the corner orientation in a very similar format. _D is the UFL cubie wctctga _E wctctga _T which is attached to the _D cubie. The '+' describes that the cycle rejoins the starting cubie with a twist and _P is the side of the _E cubie wctctga _D again.

* * generator notation * *

For an algorithm, apply it to a solved cube, and read the result as if you are about to blind-solve it. This I refer to as "generator notation". Here is it in action for the solution Ollie proposed to my challenge scramble

D L2 B2 L2 U B2 U2 B' R' U2 F2 U2 B' L D' F2 L D L2
dpsv: (KNXW_IPOQE_Fl_Bm_#_DEt+p_BKXLO_Ci-h)

. [x' : [ U':F2 ] [ R':U' ; F2 ]]
. == x' U' F2 U R' U' R F2 R' U R x
. (#_DBE)
dpsv: (KNXW_IPOQE_Fl_Bm_#_DKXLOBt+m_Ci-h)

. [L2, U' R U] == L2 U' R U L2 U' R' U
. (#_DXK)
dpsv: (KNXW_IPOQE_Fl_Bm_#_DLOBt+m_Ci-h)

. [x ; U R2 U', L'] == x U R2 U' L' U R2 U' L x'
. (#_DOL)
dpsv: (KNXW_IPOQE_Fl_Bm_#_DBt+m_Ci-h)

. [Rw ; U2 , L D2 L' ]
. == Rw U2 L D2 L' U2 L D2 L' Rw'
. (#_DJB)
dpsv: (KNXW_IPOQE_Fl_Bm_#_DC)


. [ Uw' L ; U' M' U , L ]
. == Uw' L U' M' U L U' M U L2 Uw
. (KXN_#)
dpsv: (KW_IPOQE_Fl_Bm_#_DC)

. [ Uw' x' ; M , U R U' ]
. == Uw' x' M U R U' M' U R' U' x Uw
. (KIW_#)
dpsv: (KPOQEI_Fl_Bm_#_DC)

. [ R ; U' M2 U , R ]
. == R U' M2 U R U' M2 U R' R'
. (KOP_#)
dpsv: (KQEI_Fl_Bm_#_DC)

. [ L R2 D', L ] [ U' , L' ]
. == L R2 D' L D R2 L' L' U' L' U L
. (KEQ_#)
dpsv: (KI_Fl_Bm_#_DC)

. M' U' () U F2 D' [ L2 : U ] F2 D [ R2 : U' ] () U M
. == M' U' {T-Perm} U M
. j: (KI_#_DC) // parity requires a center face twist
jdpsv: (Fl_Bm_#)

. [ F ; [ R' : U2 ] [ R , U ] R' U2 [ Rw U : R ] ]
. == F R' U2 R2 U R' U' R' U2 Rw U R U' Rw' F'
. (Fl_Bm_#)
jdpsv: (#) // solved


Speffz is not my letter system, so I invite the community familiar with Speffz to vet these computer-generated results. With TuRBo like algorithms, I find it useful to refer to the alg. set by its generator notation. Ignoring the common buffers (edge) K_ and (corner) _D, the set for this solution could read { XN_, IW_, OP_, EQ_, _BE, _XK, _OL, _JB } which is a very compact means for referring to the algorithms employed. Also, note that the reading for the scramble:

dpsv: (KNXW_IPOQE_Fl_Bm_#_DEt+p_BKXLO_Ci-h)

does not contain any assumption for which buffers are employed, or what means are employied for "breaking into" new cycles or how parity is to be resolved.

 

[adimare]

This is awesome! Is there any way to access the software?

Also, a few questions/corrections

...the first four letters "dpsv:" refer to the new orientation where the centers of each face points after the scramble.

Can you elaborate on how these letters are meant to be read/how the information can be useful?

"d" is a Speffz specification for the UL corner...

*edge

...The solution presented appears to prefer the edge buffer FD or Speffz K_...

Are you always selecting K by default or is it selected differently depending on the scramble? (same question for D as the corner buffer)

Fl_ is notation that the FL cubie at Speffz F_ is flipped in place to LF or Speffz L_. Similaly for the UR cubie at Bm_...

The lowercase letters make it a bit harder to read and don't really add any information (if F needs to be flipped you know the sticker on F goes to L and vice versa).

"#_DEt+p_BKXLO_Ci-h" is the corner orientation in a very similar format. _D is the UBR cubie wctctga _E wctctga _T which is attached to the _D cubie. The '+' describes that the cycle rejoins the starting cubie with a twist and _P is the side of the _E cubie wctctga _D again.

UFL*
Also, how are you selecting the next target when you break a cycle?

... Ignoring the common buffers (edge) K_ and (corner) _D, the set for this solution could read { XN_, IW_, OP_, EQ_, _BE, _XK, _OL, _JB } which is a very compact means for referring to the algorithms employed.

I think you still need to make a distinction between the edges and corners. Also, what happened to the edge flips and corner twists? And why are the letter pairs in reverse order?

Also, note that the reading for the scramble:
dpsv: (KNXW_IPOQE_Fl_Bm_#_DEt+p_BKXLO_Ci-h)
does not contain any assumption for which buffers are employed, or what means are employied for "breaking into" new cycles or how parity is to be resolved.

What does that mean? Doesn't that solution imply that K is used as the edge buffer and D as the corner buffer?
Here's the solution my software finds for the same scramble, it assumes U and A as the edge/corner buffers respectively:
scrambld.cubing.net

 

[leeo]

Can you elaborate on how these letters are meant to be read/how the information can be useful?

The prefix letters describe the center face twist after the algorithm is applied. For WCF compliant 3x3x3 cubes this is of no use. However BH methods prefer algs that do not twist any of the center faces. That way, they may be applied to larger cubes before all of the center faces are fixed. To read the letters, they describe a Speffz edge. The plane of that edge is the plane with the twisted center face. The initial position of each face twist is the least name alphabetically, A_ E_ I_ M_ Q_ and U_. After the algorithm, if the center face still faces its edge with the least name alphabetically, it is not mentioned. Any other facing would represent a twisted center face. "dpsv:" reperesents D_, a 90-degree twist of the U Face center, with P_, a 270-degree twist of the R face center, and so forth.

*edge

thanks, fixed. By the way, with the way Speffz is labeled, tracking the corner of each face and listing which corner is faced after the alg. is applied would give the same results.

Are you always selecting K by default or is it selected differently depending on the scramble? (same question for D as the corner buffer)

It is selected differently depending on the _solution_ I am trying to trace. The system is not a solver, but a verifier. Usually, by default, I select the least name alphabetically, and prefer an A_ edge buffer and _A corner buffer. I picked K_ edge and _D corner to follow Ollie's solution.

The lowercase letters make it a bit harder to read and don't really add any information (if F needs to be flipped you know the sticker on F goes to L and vice versa).

The lowercase letters note a re-attachment, and provide help for constructing a solution in three-cycles. It simply flags that a new cubie has not been encountered in the cycle read.

UFL*

Thanks, fixed. It often happens with translations that I cycle the "wrong way".

Also, how are you selecting the next target when you break a cycle?

I am not selecting the next target, but following Ollie's solution. My best guess is that he is "stitching" cycles together solving one edge or corner in the process. Usually two edges and corners are solved together. Personally I prefer instead to lead with the least-alphabetically name of an unvisited cubie, and plan to revist that name at the end of the cycle. This, however, is solution theory, and I am just focusing on notation.

I think you still need to make a distinction between the edges and corners. Also, what happened to the edge flips and corner twists? And why are the letter pairs in reverse order?

This can be confusing with the same letters referring to either an edge or corner. The method I came up with is based on this diagram

{faces} : ( {edges} _#_ {corners} )

this faces are components with 1 color; edges are components with 2 colors; corners are components with 3 colors.

{ 1 } : ( {2} _#_ {3} )

With the edges in position {2}, an edge appears as Z_ where "Z" is a Speffz letter. With the corners in position {3}, a corner appears as _Z where "Z" is a Speffz letter.

What does that mean? Doesn't that solution imply that K is used as the edge buffer and D as the corner buffer?
Here's the solution my software finds for the same scramble, it assumes U and A as the edge/corner buffers respectively:

I mean to say that the display is method-neutral. You do rightly point out that the display appears prefer the K_ edge and _D corner, but that is but a mere display adjustment. Here is my default reading, with the A_ edge and _A corner buffer:

bfosz: (AJUD_BLXVRTWm's_Ci_#_AHGe-u_BVq-p_CFTm-o)

In three-cycle generator form, I would apply: (_AGH) (_AVB) (_ACQ) (_ATF) (_ADM) solving the corners except for an _A _D exchange, then apply (AUJ_) (ABD_) (AXL_) (ARV_) (AWT_) (ACM_)(ADI_) solving the edges except for an A_ D_ exchange. These two exchanges together constitute "J" perm; to complete the solve.