#### Athefre

##### Member

- Joined
- Jul 25, 2006

- Messages
- 1,162

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:

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.

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.

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.

Last edited: Mar 6, 2021