Notation Based Reference System (NBRS): A standard for defining methods and states

[Athefre]

Notation Based Reference System

A team consisting of myself, RedstoneTim, zakimoshi, and trangium have developed a system for defining any state in which a puzzle can be. The system consists of three main parts. The first part is the system for referencing any group, or block, of pieces on the cube. In this, a block is referenced using the cube notation that is already familiar to the community. Outer turns and wide turns are combined to describe the location of a defined block. Just as we already reference a piece on the cube using something like UFR, which is the intersection of the U, F, and R layers, blocks can be referenced by taking the intersections of outer turns, wide turns, and slices. This makes it much easier to describe the steps of a method. Instead of writing a sentence to describe the location of a block, the block can be simply referenced using the intersection of the layers in which the pieces reside. Instead of saying "Solve a 1x2x3 on the bottom left, with all pieces on the D layer" or "Solve the 2x2x2 at DBL", it would be "Solve Dl" or "Solve dbl".



The second and third parts of the system make use of this block referencing to form a way to describe any movement of pieces and any state in which the cube can be. Much of the same notation and terminology that the community already uses to create acronyms for steps or describe color neutrality are used here. This means things such as C for corners, E for edges, O for orientation, P for permutation, and rotations (x, y, and z). It works in this way:

Pseudo/Unsolved and Color Neutrality

• To describe pseudo, first the pieces are referenced using the block reference notation above. Then an imaginary rotation is performed to describe that the pieces are located in the location that the rotation would place them. The pieces and the imaginary rotation are separated by a colon symbol. UBL:y2 describes the UBL corner currently located at UFR.
• To describe color neutrality, it works similarly to the pseudo referencing. Except here the rotation is placed before the piece location. An imaginary rotation is performed to move pieces into the location that is referenced after the colon symbol. An asterisk * can be used to denote that the rotation can go in any direction. y2*:dL describes a Roux user that is y2 neutral. They can solve one of two first blocks - the one that is on the left or the one on the right.

States:

1. First the location on the cube of a piece or group of pieces is referenced using the block reference notation.
2. If only the corners or the edges of the referenced location are to be described, they are wrapped in a corner C() or edge E() function. If not, no function is used and all pieces within the referenced location are to be described.
3. If the referenced location is to consist of pieces from another location, curly brackets {} are placed directly after the referenced location and inside the curly brackets is placed the location of those new pieces. U{D} describes a U layer consisting of only pieces from the D layer.
4. Finally, O for orientation or P for permutation are placed at the end, inside of square brackets [], to describe the pieces as being oriented or permuted. U[O] describes the U layer being oriented but not permuted, U[P] describes the U layer being permuted but not oriented, and U[O, P] (or just U[]) describes the U layer as being both oriented and permuted. Rotations x, y, and z can be included when being specific about the type of orientation.

Taking the above parts of the system, individual block and state definitions can be chained together using + or - symbols to describe a method or the complete state of the cube. As an example, to describe the EOLine variant of ZZ with OCLL and PLL for the last layer, it would be E()[O(z)] > dM > dL + dR > C(U)[O] > U[P]. The system can describe everything from something as simple as the state of a single piece all the way to the most abstract states.

NBRS has so far been primarily developed for 3x3x3. However, it can also be used on any other puzzle. For other puzzles, the notation would be dependent upon the way in which turns, rotations, and other things like edge orientation are defined. Work hasn't started on putting together the details for other puzzles, but that is a future plan. The notation is simple to use. However, if anyone has questions about how to notate a specific state, please ask and we will assist. We would also like feedback from the community on things that would be good to incorporate.

 

[PapaSmurf]

@everyone, check out the website and use this - it's super cool!

For Petrus, would the steps using NBRS would be:
dbl->db->db+E()[O(x)] -{y'}-> d+E(U)[O(y)]->solved?
Also (just thought about it doing this), -{rotation}-> as a transition between steps? Depends on how compact you'd want it to be and how useful that would be (as most methods simply don't have any rotations between steps, so would be pretty useless).

The only situation I can see this not covering is 2-gen reduction. Eg. for Briggs: dL+C(RU)[2GR]->dl+C(RU)[2GR]+E()[O(z)]->d+C(U)[P]->solved. You could alternatively use C(RU)[P], but that could also mean you place every corner in the correct place, which isn't what it is. Anyway, this is only one super niche case which can be easily fixed, otheriwse this is amazing!

 

[Athefre]

@everyone, check out the website and use this - it's super cool!

For Petrus, would the steps using NBRS would be:
dbl->db->db+E()[O(x)] -{y'}-> d+E(U)[O(y)]->solved?
Also (just thought about it doing this), -{rotation}-> as a transition between steps? Depends on how compact you'd want it to be and how useful that would be (as most methods simply don't have any rotations between steps, so would be pretty useless).

The only situation I can see this not covering is 2-gen reduction. Eg. for Briggs: dL+C(RU)[2GR]->dl+C(RU)[2GR]+E()[O(z)]->d+C(U)[P]->solved. You could alternatively use C(RU)[P], but that could also mean you place every corner in the correct place, which isn't what it is. Anyway, this is only one super niche case which can be easily fixed, otheriwse this is amazing!

For Petrus I would do: dbl > dbR > E()[O(x)] > :y' > dR > U. Interesting point about rotations. For example solves, we haven't yet had to use those. So it was good to notice that those can also be included in the solution.

For 2-gen reduction, that is also interesting. The system does include custom, user defined functions. So maybe we could have a 2G() function and place the corner layers inside.

 

[abunickabhi]

Notation Based Reference System

A team consisting of myself, RedstoneTim, zakimoshi, and trangium have developed a system for defining any state in which a puzzle can be. The system consists of three main parts. The first part is the system for referencing any group, or block, of pieces on the cube. In this, a block is referenced using the cube notation that is already familiar to the community. Outer turns and wide turns are combined to describe the location of a defined block. Just as we already reference a piece on the cube using something like UFR, which is the intersection of the U, F, and R layers, blocks can be referenced by taking the intersections of outer turns, wide turns, and slices. This makes it much easier to describe the steps of a method. Instead of writing a sentence to describe the location of a block, the block can be simply referenced using the intersection of the layers in which the pieces reside. Instead of saying "Solve a 1x2x3 on the bottom left, with all pieces on the D layer" or "Solve the 2x2x2 at DBL", it would be "Solve Dl" or "Solve dbl".

View attachment 15050

The second and third parts of the system make use of this block referencing to form a way to describe any movement of pieces and any state in which the cube can be. Much of the same notation and terminology that the community already uses to create acronyms for steps or describe color neutrality are used here. This means things such as C for corners, E for edges, O for orientation, P for permutation, and rotations (x, y, and z). It works in this way:

Pseudo/Unsolved and Color Neutrality

• To describe pseudo, first the pieces are referenced using the block reference notation above. Then an imaginary rotation is performed to describe that the pieces are located in the location that the rotation would place them. The pieces and the imaginary rotation are separated by a colon symbol. UBL:y2 describes the UBL corner currently located at UFR.
• To describe color neutrality, it works similarly to the pseudo referencing. Except here the rotation is placed before the piece location. An imaginary rotation is performed to move pieces into the location that is referenced after the colon symbol. An asterisk * can be used to denote that the rotation can go in any direction. y2*:dL describes a Roux user that is y2 neutral. They can solve one of two first blocks - the one that is on the left or the one on the right.

States:

1. First the location on the cube of a piece or group of pieces is referenced using the block reference notation.
2. If only the corners or the edges of the referenced location are to be described, they are wrapped in a corner C() or edge E() function. If not, no function is used and all pieces within the referenced location are to be described.
3. If the referenced location is to consist of pieces from another location, curly brackets {} are placed directly after the referenced location and inside the curly brackets is placed the location of those new pieces. U{D} describes a U layer consisting of only pieces from the D layer.
4. Finally, O for orientation or P for permutation are placed at the end, inside of square brackets [], to describe the pieces as being oriented or permuted. U[O] describes the U layer being oriented but not permuted, U[P] describes the U layer being permuted but not oriented, and U[O, P] (or just U[]) describes the U layer as being both oriented and permuted. Rotations x, y, and z can be included when being specific about the type of orientation.

Taking the above parts of the system, individual block and state definitions can be chained together using + or - symbols to describe a method or the complete state of the cube. As an example, to describe the EOLine variant of ZZ with OCLL and PLL for the last layer, it would be E()[O(z)] > dM > dL > dR > C(U)[O] > U[P]. The system can describe everything from something as simple as the state of a single piece all the way to the most abstract states.

NBRS has so far been primarily developed for 3x3x3. However, it can also be used on any other puzzle. For other puzzles, the notation would be dependent upon the way in which turns, rotations, and other things like edge orientation are defined. Work hasn't started on putting together the details for other puzzles, but that is a future plan. The notation is simple to use. However, if anyone has questions about how to notate a specific state, please ask and we will assist. We would also like feedback from the community on things that would be good to incorporate.

Nice idea. This way of expressing states and methods is too mathematical. I am not sure if this language or way of describing gets widely adopted by the cubing community.

I would love to see NBRS being developed more. Good work!

 

[PapaSmurf]

Nice idea. This way of expressing states and methods is too mathematical. I am not sure if this language or way of describing gets widely adopted by the cubing community.

I would love to see NBRS being developed more. Good work!

It has to be mathematical if you want to be clear with no ambiguation. The amount of times people have said "solve a square at BR" and you're confused to whether it's dbR, dBr, Dbr etc. means that even just the first, intuitive section could easily be adopted by people who just understand notation. I agree that the rest of it is less likely to be used, but even then it's very handy to have. It's the same as not everyone needing to know how to solve a quadratic, but for people who encounter maths often, it is very useful to know how to solve one.

 

[Athefre]

Nice idea. Below is how I would express those cases in this type of notation. (So that it can generalize to the nxnxn.) You can replace the intersection symbol with a period (dot) to make shorter expressions. The three cases I didn't comment on are OK to me (or I couldn't think of anything better).

• Visible (specific pieces that matter/are being considered) pieces that move, move by the sequence after @.
• If moves are done (again, the letters are after the @) but pieces in reach of those moves don't matter, they are not mentioned in the expression.
• When pieces are "subtracted" at the end of an expression, it's assumed that all other pieces (which are not mentioned in the expression) are visible/matter.
• U() in the last (bottom-right) case can be U(C+E). It just represents all pieces in U. (Same for D().)

And of course:

• We clearly agree on many things.
• I acknowledge that this is your project, not mine. So I am in no way enforcing it be like this. It's just that maybe you just wanted to hear what I thought about it.
• This is the best way I could express how I think about it.

____________________________________________________________________________
View attachment 15066

_______________________________________________________________________
EDIT:
On second thought, the @ny should be removed from the expressions I mentioned them in. (It makes no sense, because the corners can be permuted in more than 4 ways in the corner case, and the same for the edges.

EDIT2:
I have updated those two cases (updated the image).

EDIT 3:
The expression with F(2),R(1), etc. was incomplete. Fixed.

EDIT 4:
Oh, and somehow it got cut off from cut and pasting, but the caret symbol is the (discrete) math symbol for AND.

Something interesting: Early on when I was developing this with the group, I actually did bring up the idea of just using that notation for the system. However, the goal was to create something that the entire community can understand and use. There is a side of the community that is into mathematics, programming, and other technical things. But there is also the larger side that just wants to solve the cube and talk about what they are doing. I think it is the right choice to have it specialized for the puzzle community as a whole, as evidenced by some already saying that it is complex or mathematical. Any further into mathematics and the general community would have no interest.

There is a modification to the functions that was recently suggested by Joseph Briggs. The site will soon be updated with that. It covers all puzzles without being restricted to EO, EP, CO, and CP functions. Those functions work well on 3x3 and are simple, but other puzzles don't have the same properties.

 

[Cubing Forever]

Nice idea, @Athefre !! I found this on your website a day or two before you made this thread(cool website tho, btw). It seemed way too complex at first but I understand a bit now. However, I'm still stuck at the pseudo/unsolved referencing stuff.
This system could be useful for method developers for presenting methods in one short sentence instead of a 1000 word essay.


(btw, great fan of your work in method development)

E: someone said that this way of expressing states is too mathematical.
Believe me, all the functions and stuff may seem complex at first but this system is actually a very simple and lucid way of representing methods.

 

[Athefre]

Nice idea, @Athefre !! I found this on your website a day or two before you made this thread(cool website tho, btw). It seemed way too complex at first but I understand a bit now. However, I'm still stuck at the pseudo/unsolved referencing stuff.
This system could be useful for method developers for presenting methods in one short sentence instead of a 1000 word essay.


(btw, great fan of your work in method development)

Thank you!

A simple way of thinking about the Pseudo/Unsolved notation is that you are moving a piece or group around the cube by just using rotations. Centers are ignored. The order is x, then y, then z to get a piece or group where you want it to be.

- If you want to say that the edge UFM is flipped at UBM: An x rotation of the cube flips UFM to UBM. So the notation would just be UFM:x.
- If you want to say that UFM is oriented at UBM: No number of x rotations can do that. So move on to using y. y2 places UFM at UBM, so it would be UFM:y2.
- If you want to say that UFM is flipped at URS: Starting with x, an x rotation will flip the edge. Then a y rotation will place it at URS. So it would be UFM:xy.

 

[Cubing Forever]

Roux NBRS should be Dl>Dr>C(U)[]>E(U,D)[] right?
(correct me if I'm wrong)
E: thanks for the explanation @Athefre

 

[Athefre]

Roux NBRS should be Dl>Dr>C(U)[]>E(U,D)[] right?
(correct me if I'm wrong)

Close. It would be dL > dR > C(U) > E(US + M).

dL references the 1x2x3 on the left because L is the outer layer turn. Dl would be a 1x2x3 on the D layer. Also, the notation can be simplified for writing purposes as I did above. There is no need to write the full notation as in C(U)[]. For the general user, the final set of brackets isn't necessary. And if you want to be specific about centers, E(US + M) could just be US + M.

 

[Cubing Forever]

How do you deal with symmetry as in you can choose which F2L pair you want to solve in CFOP, which 3QB edge you want to solve in Mehta etc.?

E: One thing I thought of is using a sym() function where you put the pieces to solve inside the brackets.
For eg. sym(dFR, dBR, dFL, dBL) would be F2L in CFOP. The sym() function would mean that you can solve those particular pieces in any order.
Another example would be sym(FRE, FLE, BRE, BLE) which is the 3QB step of the Mehta method.

What are your thoughts on this idea, @Athefre ?

 

[Athefre]

How do you deal with symmetry as in you can choose which F2L pair you want to solve in CFOP, which 3QB edge you want to solve in Mehta etc.?

E: one thing I thought of is using a sym() function where you put the pieces to solve inside the brackets.
For eg. sym(dFR, dBR, dFL, dBL) would be F2L in CFOP. The sym() function would mean that you can solve those particular pieces in any order.

For a specific order we have the transition, >, for steps. To solve things in any order, + covers that.

dFR > dFL > dBL > dBR = Solve the pairs in that order.
dFR+dFL+dBL+dBR = Solve the pairs in any order.

 

[Cubing Forever]

With the little knowledge I have about NBRS, here's some methods represented by it.
CFOP: DFM+DBM+DRS+DLS>dFR+dBR+dFL+dBL>U[O]>U[P]
Roux:
dL>dR>C(U)>E(US+M)
ZZ-a with EOCross:
E()[O(z)]>DFM+DBM+DRS+DLS>dFR+dBR+dFL+dBL>U[O,P]
Mehta TDR:
Dl>BRE+FLE+BLE>FRE+E()[O(z)]>DR>U[O,P]

correct me if I'm wrong.

E: ZZ-a is ZZ with ZBLL for those who don't know

 

[Athefre]

With the little knowledge I have about NBRS, here's some methods represented by it.
CFOP: DFM+DBM+DRS+DLS>dFR+dBR+dFL+dBL>U[O]>U[P]
Roux:
dL>dR>C(U)>E(US+M)
ZZ-a with EOCross:
E()[O(z)]>DFM+DBM+DRS+DLS>dFR+dBR+dFL+dBL>U[O,P]
Mehta TDR:
Dl>BRE+FLE+BLE>FRE+E()[O(z)]>DR>U[O,P]

correct me if I'm wrong.

E: ZZ-a is ZZ with ZBLL for those who don't know

Looks very good. Though some things can be further simplified.

CFOP: dM+dS > dFR+dFL+dBL+dBR > U[O,P]
Roux: dL > dR > C(U) > US+M
ZZ-a with EOCross: EO()[O(z)] > dM+dS > dFR+dFL+dBL+dBR > U
Mehta TDR: Dl > BRE+FLE+BLE > FRE+E()[O(z)] > DR > U

 

[Cubing Forever]

dM+dS

That would mean you should solve two opposite cross edges at a time right? That is clearly not the case with CFOP and ZZ.

 

[Cubing Forever]

Sorry for double post, but 2 things this system does not cover are pseudo EO and 2 Gen Reduction. for 2 gen reduction, we can use the function 2G() as mentioned above. How can we represent pseudo EO?
(pseudo EO is orienting only a few edges at a time instead of all of them. The methods currently using it are YruRU and Hawaiian Kociemba)

 

[Athefre]

That would mean you should solve two opposite cross edges at a time right? That is clearly not the case with CFOP and ZZ.

Yeah, that's true. However, in that case I wasn't really trying to emphasize that someone can solve in any order. Because it's just a general statement of solving the edges. Notating individual edges are best if someone really wants to emphasize that they are solving in any order. Otherwise, you can be more free and just notate the blocks. For example, I would just notate CFOP as DM+DS > d > U[O,P] or E(D) > d > U[O,P] or any other simplified version because for general community use where we don't have to be specific as in a program, things are easily assumed and it's ok to do so. For programming it is important to be specific with the use of the notation.

Sorry for double post, but 2 things this system does not cover are pseudo EO and 2 Gen Reduction. for 2 gen reduction, we can use the function 2G() as mentioned above. How can we represent pseudo EO?
(pseudo EO is orienting only a few edges at a time instead of all of them. The methods currently using it are YruRU and Hawaiian Kociemba)

For 2-Gen, Joseph Briggs' recent idea for the system is a solution to that and helps with many other things. That will be added to the site soon. For partial EO, that is an interesting question. We haven't yet tried to represent x/y in anything. Maybe a third, rare parameter in the functions or by using *, |, or a number. I'll bring that up in the server and see what everyone thinks.

 

[RedstoneTim]

That would mean you should solve two opposite cross edges at a time right? That is clearly not the case with CFOP and ZZ.

I actually believe that one should only consider the total outcome since solving after each other is what the state transition notation is for. That would mean that dM + dS doesn't require you to solve in any order, you only need to get to the state of cross. dM > dS, however, would mean that you're building the cross using opposite pieces.

 

[Cubing Forever]

A more simplified Mehta TDR NBRS:
Dl>lE>BRE>FRE+E[O(z)]>DR>U[]

 

[PapaSmurf]

Before this goes any further, you're both adults. Stop. We're discussing a plastic toy, don't forget that. Instead, let's acknowledge the utility of the system, that things are rarely original and that whatever has happened, NBRS has standardised and expanded on previous reference systems, which is great. What someone has done will be insignificant eventually (unless you're an Isaac Newton or Michaelangelo), so let's use everything as we have and work for the bettering of the community as a whole.