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



## Athefre (Mar 4, 2021)

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:*

First the location on the cube of a piece or group of pieces is referenced using the block reference notation.
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.
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.
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 (Mar 4, 2021)

@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 (Mar 4, 2021)

PapaSmurf said:


> @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?
> ...



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 (Mar 5, 2021)

Athefre said:


> 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".
> 
> ...


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 (Mar 5, 2021)

abunickabhi said:


> 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 (Mar 8, 2021)

Christopher Mowla said:


> 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.
> ...



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 (Mar 11, 2021)

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 (Mar 11, 2021)

Cubing Forever said:


> 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 (Mar 11, 2021)

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 (Mar 11, 2021)

Cubing Forever said:


> 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 (Mar 11, 2021)

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 (Mar 11, 2021)

Cubing Forever said:


> 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 (Mar 11, 2021)

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 (Mar 11, 2021)

Cubing Forever said:


> 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)
> ...



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 (Mar 11, 2021)

Athefre said:


> 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 (Mar 11, 2021)

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 (Mar 11, 2021)

Cubing Forever said:


> 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.



Cubing Forever said:


> 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 (Mar 11, 2021)

Cubing Forever said:


> 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 (Mar 11, 2021)

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


----------



## PapaSmurf (Mar 11, 2021)

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.


----------



## Athefre (Mar 12, 2021)

For those interested in the history of this system, here is the origin:









Random Cubing Discussion


I learned heise D2 B' D2 L B D2 B' L' F' B' D2 L B' D' R' D R U2 R D R L U2 B' F y2FR2UR DBUB'U2z2 LR'FRL'UL'U'L y'RU'R' B2D2F2 xL'ULU'R'UL'U'Lx' D2B2U2L' 38 moves Lately I've been using ZZ with the Heise two pair, three corner ending because I got tired of memorizing and...




www.speedsolving.com





This is the original, very simple post that I made about the block referencing notation. It is the earliest that we know of so far for referencing blocks in this way. And the only one we know of that was fully developed. After I made that post I shared the idea in the chat room and talked about the benefits.

Then, in January of this year, I talked about the idea again in the ZZ Discord server. Others really liked the idea and it developed from there. The credit for the extensions can be seen on the site.


----------



## Roman (Mar 12, 2021)

First of all, this is a huge amount of work and I haven't went through every post in this thread yet.

If I understood correctly, it is possible with this method to reference/describe one and ths same cube state in multiple different ways. For example, by listing the unsolved pieces with their current positions in different order I will end up with different strings (in terms of programming) in NBRS notation that basically describe identical cube states.

I am currently looking for a way to avoid this ambiguity when describing cases occuring in BLD solves. So far I've came up with cube cycles canonical representation but it is still imperfect. Can NBRS be an ultimate solution for mitigating the ambiguity I'm describing, or is it totally not intended for that?



Spoiler: Problem with 3cycles notation



Consider this edge 3cycle: UF-FD-RU. It is the same 3cycle as DF-UR-FU and yet the same as FD-RU-UF. This ambiguous way of referring to the same 3cycle in different ways may become a problem when, for instance, we store the algorithms for this 3cycle case in the relational database. If the primary key for the 3cycle case is "UF-FD-RU" and someone searches algorithms for "UR-FU-DF" (e.g. as a set of algorithms for FU-DF cycle with UR floating buffer), he expects to obtain the same results as if he would by searching for "UF-FD-RU".

In order to achieve this, we can use canonical representation of this cycle as a primary key for the 3cycle case. This way, no matter how the user will type in this case, it will first be converted into the canonical representation and then the DB lookup will take place.

Link: https://docs.google.com/document/d/1Eexb0EI5473gcbc81gMj8i4ZHb1Z7uqn_tzG7Tfzw10/edit#


----------



## Christopher Mowla (Mar 12, 2021)

@Roman ,
This notation is not for representing pure cycles. It's for representing _partial solves_. (According to @RedstoneTim , if I understood him correctly on Discord.)

And the ambiguous cycle representation for the search can be taken care of by a "cycle rotation script". So basically it can search for all possibilities so that the user doesn't have to care about being specific. So basically, it will rotate what is searched for until it either finds a match or has gone through all k rotations for a k-cycle. That way, you can represent the cycle however you want in the database, spreadsheet, etc., but the user will still be able to find it. (I am glad that you said this, because I didn't think about that for my soon to be worked on Excel spreadsheet script for @abunickabhi in this thread.)

Alternatively, you can number all pieces like I did in my custom 3x3x3-7x7x7 numbered cubes for CubeTwister such that the convention would be that you just always represent the cycle by starting with the smallest (or largest) number in the cycle. (That's a fool-proof way of doing it without a script.)

Example:
The cycle (5->10->3) = (3->5->10) = (10->3->5). If we choose to represent all cycles by starting with the smallest number, it would only have the "unique" representation *(3->5->10)*.


----------



## abunickabhi (Mar 12, 2021)

For BLD cycles, if the user chooses to trace from FU instead of UF, or wants the cycle 2-3-1, which is the same as 1-2-3, a different mathematical way of representation will be needed other than NBRS. I will have to read out cube cycle canonical rep documentation.

As Christopher said, if we want to search for cycles partially in an excel sheet format, it can be done via programming. I do not know the details of that, but the overall idea is to split up a cycle targets into columns, eg UF-DF-RU to column 1, UF, column 2 DF and column 3 RU, and apply some transposition or similarity operations there.

People are coming with smarter way nowadays to represent comm notation as well, like [A:[B,C]] be represented as A/B,C and so on. The BLD sheet of Elliot has this new notation. But here we are trying to reduce ambiguity of cycles which is a different optimization task.


----------



## RedstoneTim (Mar 13, 2021)

Christopher Mowla said:


> This notation is not for representing pure cycles. It's for representing _partial solves_. (According to @RedstoneTim , if I understood him correctly on Discord.)


NBRS aims to describe all kinds of states, including partial but also completely defined ones. Methods can then be described as transitions between states.
However, due to the underlying system of using the notation to define blocks, NBRS is best used for the partial states which usually appear in methods since that ends in shorter and more understandable notation.
This does not mean that it is _impossible_ to describe concrete states, but it's a bit harder since that is not exactly what the system was made for. For example, a Niklas would be d+E(U)+UFL+UFR:z'y'+UBR:x'+UBL:z.



Roman said:


> Can NBRS be an ultimate solution for mitigating the ambiguity I'm describing, or is it totally not intended for that?


NBRS isn't an unambiguous notation as we decided to add shortcuts at the price of ambiguity. An example of this is the F2L-1 state (with the missing pair in FR), which you could describe as d-dFR or dl+dRb. The former is usually preferred, but the latter is also a valid option.

All in all, I think that NBRS is sadly just not made for this kind of purpose.


----------



## Julio974 (Aug 30, 2021)

If I got this right, Human Thistlethwaite can be described as:

E()[O(y)] > E()U+D{U+D}[O] > C()[O] > C()[P] > E()[P] > [P]

Though I'm not sure how to write down the fact that opposite colors are only distinguished in steps 3, 4, and 6


----------

