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

[Athefre]

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]

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]

@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]

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]

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.

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]

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