# New notation idea



## qqwref (Apr 19, 2011)

Here is a notation that:

can represent all block turns (turning layers P through Q on a puzzle) in one move, and 
is unambiguous, _without spaces_, for cubes of any size.

The notation works like this: the basic formula for a move is something like R3#7. There are four parts to each move:

The letter means the axis we are working with, and this should always be some series of letters (for instance if we are using an edge turning puzzle for some reason we could use the UR axis). In this case it's the R face.
The first number is the starting layer, or the lowest layer. We can omit this number if it is 1 (that is, our turn includes the outermost layer of the cube).
The second number is the ending layer, or the highest layer. So this move turns layers 3-7 (counting from the R face). We can omit this number if it would be equal to the starting layer (that is, our turn only affects one layer).
The # symbol is the amount of turn. The possible symbols are # for +2 (since it looks like two +s), + for +1, O for 0, - for -1, and = for -2 (since it looks like two -s). Of course, these turn directions are all relative to the axis previously mentioned. It's important not to omit this because it provides a separation between the two numbers, but also between two adjacent axes if we are omitting lots of numbers.

Here are a couple of comparisons between moves written in SiGN and moves written in this new notation, in case I didn't explain well enough:

```
SiGN | R2  R2'  2R'  r'   (r 2U2)  (r2 U2)  2-3r
this | R#  R=   R2-  R-2  R+2U2#   R#2U#    R2+3
```

We can easily extend this to use x, y, z (with no numbers) and M, E, S (with one number for how many slices on each side to ignore) if we want. Note that, without any modifications, this notation extends to N-layer variations on megaminx and pyraminx (not to mention helicopter cubes, skewbs, and so on).

Anyway, I don't expect anyone to change over to this notation (I know I won't), but I thought it had some interesting properties so I wanted to share the idea.


----------



## Kirjava (Apr 19, 2011)

I like that it doesn't have a space required between each move (like SiGN does). Can't see it catching on though.

I rarely use SiGN as it is, context usually removes ambiguity when sharing algs over IRC.


----------



## Lucas Garron (Apr 20, 2011)

Interesting idea; it's reasonably intuitive and compact. My biggest qualm with all current schemes is their lack of prefix/self-delimiting code syntax.

Unfortunately, I would need some good reason to convince me that this could be established as a standard (instead of being "just another notation" to know/support), and why we should allow it to be incompatible with 30 years of standard notation.


----------



## StachuK1992 (Apr 20, 2011)

qqwref said:


> I don't expect anyone to change over to this notation (I know I won't), but I thought it had some interesting properties so I wanted to share the idea.


 


Lucas Garron said:


> Unfortunately, I would need some good reason to convince me that this could be established as a standard (instead of being "just another notation" to know/support), and why we should allow it to be incompatible with 30 years of standard notation.


 He wasn't offering the idea as something to adapt or change to, but rather just as an idea, if I'm interpreting correctly.

As for my opinion: Personally, I *like* spaces. It helps me read. It bothers me already when, even in context, people write algs as RUR'U'R'F, it just feels compacted and takes longer to read for me.


----------



## qqwref (Apr 20, 2011)

Unfortunately, it's really hard to make a general extension of the standard 3x3 notation without forcing spaces to be used. Allowing multiple-letter axis names (such as UF, for puzzles with edge axes) forces it unless you require every move (even clockwise turns) to contain a delimiter. Allowing arbitrary layer numbers doesn't work unless you add a delimiter or use sub/superscripts. I don't really mind having spaces in my algs (in fact they ARE harder for people to read without them), but it would be more elegant if they were completely optional.

Unrelated idea for a SiGN-like extension of normal notation: Have more than one set of angle suffixes. For instance, suppose we use [", ', ,. ,:] for a multi-layer turn, but [=, -, +, #] for a slice turn. I'd like to avoid 2 because we really need numbers for layer markers, and keeping them separated from the suffix is too difficult without super/subscripts. Then R indicates "one layer", r indicates "two layers", and we can continue with r3, r4, etc. I'll translate an alg:
normal notation: Lw2 U r' D2 r U' r' D2 r Lw2
this idea: l: U. r- D: r+ U' r- D: r+ l:
The benefit here is that multislice and slice turns are on equal footing, without either requiring an extra symbol or number.


----------



## StachuK1992 (Apr 20, 2011)

A different idea that's only relevant in the fact that it's an alternate or additional notation.

Functional programmers?
Functional notation. Just a quick idea: 
(i R U R' U') being the *i*nverse of the operands
(com (R U R' U') (M')) == [R U R' U', M']
Yes, this is extremely silly. Just an idea. Not sure what other operators could be used.


----------



## Erzz (Apr 20, 2011)

StachuK1992 said:


> A different idea that's only relevant in the fact that it's an alternate or additional notation.
> 
> Functional programmers?
> Functional notation. Just a quick idea:
> ...


 
Reminds me of lisp.

This notation seems kinda complicated, and you have to read ahead to do be able to do it, since turn number/direction comes before ending layer. Or I'm understanding it wrong.


----------



## Dene (Apr 20, 2011)

A problem that I see is that it's not simple enough for newcomers.


----------



## qqwref (Apr 20, 2011)

StachuK1992 said:


> A different idea that's only relevant in the fact that it's an alternate or additional notation.
> 
> Functional programmers?
> Functional notation. Just a quick idea:
> ...


> (defun comm (x y) (join x y (i x) (i y)))
> (comm (comm R U) (i M))
[R, U, R', U', M', U, R, U', R', M]


----------



## reThinking the Cube (Apr 22, 2011)

qqwref said:


> The # symbol is the amount of turn. The possible symbols are # for +2 (since it looks like two +s), + for +1, O for 0, - for -1, and = for -2 (since it looks like two -s). Of course, these turn directions are all relative to the axis previously mentioned. It's important not to omit this because it provides a separation between the two numbers, but also between two adjacent axes if we are omitting lots of numbers.



I really like this idea. A confusing drawback of SiGN is that numbers, especially "2", are needed to symbolize too many different things; half turns like R2, or starting on the 2nd layer like 2R2, 2R, or 2r2, or 2 layers wide like 2-3r2. Stringing these types together with other turns that also begin or end with a numeral, produces algs that look rather complicated, and clearly shows why delimiters are required with the SiGN syntax. For this reason, when writing algs by hand, I use superscript to indicate half-turns like 2R², but using the # symbol would be just as good (2R#). Your other delimiting symbols for amount of turn (+,-,=) are also very good, and more are obviously possible for puzzles that have extra rotational options.



qqwref said:


> Here is a notation that:
> 
> can represent all block turns (turning layers P through Q on a puzzle) in one move, and
> is unambiguous, _without spaces_, for cubes of any size.



qqthis 4-part notation idea = [ axis | starting layer | amount of turn | ending layer ] 

Thus inspired, I decided to combine your idea above with some modifications of SiGN to create an even better universal twisty puzzle notation:

reVolution™ = [ OFFSET | AXIS | #OF LAYERS | AMOUNT OF TURN ] 

OFFSET - is the distance in layers, from the axis face to the starting layer. Omitted if equal to 1 (anything including a face turn will not have an offset). In the example (2r+), the offset of "2" would indicate that the 2nd layer from the R face, is the starting layer. If a turn in an alg, starts with a number, then an offset is applied to the axis, otherwise there is no offset.

AXIS - borrowing from qqwref's definition; "means the axis we are working with, and this should always be some series of letters (for instance if we are using an edge turning puzzle for some reason we could use the UR axis)." The convention; uppercase (R,U,L,D,F,B) indicates one layer, and lowercase (r,u,l,d,f,b) indicates two or more layers. Doing it this way, maintains consistency with standard 3x3x3 notation, and is more concise. Also, to have a slice move notation that is consistent for cubes of any size, the smallest symmetrically centered layer is uppercase (M,E,S), and symmetrically centered slices of 3 or more layers are lowercase (m,e,s). This is not the same as qqwref's suggestion of indicating the number of layers to ignore, but rather how many symmetrical layers to include, and is the intuitively natural way to describe these slice turns.

NUMBER OF LAYERS - is simpler and more practical than [ending layer]. Can be omitted altogether, if it is implied by the case of the letter used to represent the axis. As mentioned above, uppercase axis indicates "one layer", while lowercase axis indicates "two or more layers". So R = 1 layer, r = 2 layers, r3 = 3 layers, r4 = 4 layers etc.

AMOUNT OF TURN - is specified using the symbols as in qqwref's idea above. An important improvement here is that the amount of turn symbol is always at the end of the turn designation. This is less confusing, and more consistent, than imbedding it between the starting and ending layer numerals (which are not always present, as in the R-2 example below). 

For comparison:


```
SiGN         | R2   R2'  2R'   r'    (r 2U2)     (r2 U2)    2-3r
qqthis       | R#   R=   R2-   R-2    R+2U2#      R#2U#     R2+3
reVolution™  | R#   R=   2R-   r-     r+2U#       r#U#      2r+
```

M2 U' M2 U2 M2 U' M2 (standard 3x3x3 H-perm) => 
M# U- M# U# M# U- M# (reVolution™ notation with optional spaces)

R U R' U' R' F R2 U' R' U' R U R' F' (standard 3x3x3 T-perm) => 
R+U+R-U-R-F+R#U-R-U-R+U+R-F-

2R2 U2 2R2 u2 2R2 2U2 (SiGN 4x4x4 PLL) =>
2R#U#2R#u#2R#2U#

Rw U2 x Rw U2 Rw U2 Rw' U2 Lw U2 Rw' U2 Rw U2 Rw' U2 Rw' (WCA 4x4x4 lucasparity) =>
r+U# x+ r+U# r+U# r-U# l+U# r-U# r+U# r-U# r-U# 

Rw U2 Lw' U2 x' Rw' U2 Lw U2 Rw' U2 Lw U2 Lw' U2 S2 (WCA 4x4x4 reParity™) =>
r+U# l-U# x- 2(r-U#l+U#) l-U# S#

2-3r' 2-3u 2-3r 2-3u' (SiGN 5x5x5 pixeling pattern) =>
2r-2u+2r+2u-

2-6r' (SiGN 7x7x7 center block turn) =>
m3


----------



## Kirjava (Apr 26, 2011)

Dene said:


> A problem that I see is that it's not simple enough for newcomers.


 
This isn't trying to appeal to people who can't XYX'Y' in the first place.


----------



## fagundes (Jun 30, 2011)

nice. but i think better the old.


----------



## mrCage (Jul 10, 2011)

Hi, I still prefer the natural extension to the official WCA notation (that only uses outer blocks).

It's basically only a "factoring" notation.

WCA : 3R2 R2 (turns an inner 2-layer block by 180 degrees.)

New: (3,1)R2 { or (1,3)R2 } These to have same effect but indicates different way to perform the block turn ...

Just an idea.

Naturally extends to axial notation like so: (1,2)(4,6)R2 (7x7x7 example)

Per


----------

