Change in commutator notation

[leeo]

The notation for commutators, stable for years, recently changed. The precedence rules were removed, and the ";" was removed from the notation.

I have completed a parser that expands the old standard commutator notation, and would like to begin a discussion as what to include to bring the notation and my parser back into compliance. I like to work with examples, so here it goes.

[D,L] == D L D' L' // standard commutator form
[U:F] == U F U' // standard conjugate form

This is all that remains of the standard currently. I can see how unintuitive the ";" was in the notation, so I will agree with its removal. However, I see nothing wrong with the understanding that "," is seen everywhere as a form of separator, so why not stipulate that "," binds less strongly than ":"

[U,L:F] == [U,[L:F]] == [U,L F L'] == U L F L' U' L F' L'

Now, I prefer [U,L F L'] to [U,L:F], but things get interesting with

[U F,B D:R] == [ U F, [B D:R]] == [U F, B D R D' B' ] == U F B D R D' B' F' U' B D R' D' B'

What I did this evening was to permit "::" as a replacement for the old ";", and would not miss the removal of ";" -- no one used it. Still, the setup moves, apply algorithm X, undo setup moves motif is very common. So how about the following?

[U :: L:B ] == [ U : [ L:B ] ] == [ U : L B L' ] == U L B L' U'
[U :: F,D ] == [ U : [ F , D ]] == [ U : F D F' D' ] == U F D F' D' U'

now for the following corner conjugate, which I leave to the reader to figure out what it does:

[ F :: F L2 F' , R' ] == [ F : [ F L2 F' , R' ]] == [ F : F L2 F' R' F L2 F' R ] == F F L2 F' R' F L2 F' R F' == F2 L2 F' R' F L2 F' R F'

It should be very intuitive that "::" is simply ":", but it will bind only after "," or ":", much as "my dear aunt sally", where _m_uliplication and _d_ivision binds stronger in algebraic equations than _a_ddition and _s_ubtratction.

 

[Lucas Garron]

The notation for commutators, stable for years, recently changed. The precedence rules were removed, and the ";" was removed from the notation.

You mean on the wiki? I removed my old proposal (which someone else had added to the wiki – I don't know who). No one used it, and https://alg.cubing.net/ doens't even support it (even though it would be trivial for the alg.js parser to support it).

I have completed a parser that expands the old standard commutator notation, and would like to begin a discussion as what to include to bring the notation and my parser back into compliance.

Apart from the WCA Regulations, there are no official definitions. Just conventions.

It should be very intuitive that

To me, this is the core of the problem. I realized that no option is actually intuitive.
However, the alternative of nesting commutators is unambiguous. In practice, it's usually not much worse to write out structured algs justing just commutators and conjugates.


But you can always try new ideas. There are people on this forum who work with algs a lot, and maybe they'd prefer your suggestion.

 

[newtonbase]

I've been prepping for comms as I plan to learn after my next comp. I've struggled to understand what the ";" actually means. The alg lists I've found describe [A; B] as "A B A' with one move cancelled" which makes no sense to me. What move is cancelled? A system without this would be great. A list of full algs for 3BLD would be even better.

 

[Goosly]

I've struggled to understand what the ";" actually means. The alg lists I've found describe [A; B] as "A B A' with one move cancelled" which makes no sense to me.

It doesn't make sense indeed. The wiki has useful information: Commutators_and_Conjugates
Sometimes ; is used instead of ,

 

[Lucas Garron]

It doesn't make sense indeed. The wiki has useful information: Commutators_and_Conjugates
Sometimes ; is used instead of ,

This is a great example of why I removed the section of my proposed notation on the wiki.

; was a (low-precedence) version of : rather than ,

No one ever kept it straight. ;-)

 

[Christopher Mowla]

When I made hundreds of short parity algorithms from 2009-2013 by hand, I came up with my own move notation for private use to maximize the efficiency of my research because the commonly used notation just wasn't the best fit for my taste. I tried to get it popularized, but it didn't happen.

In a PDF I made later showing my decompositions of many of my and a few commonly practiced parity algorithms (Parity algorithm commutator/conjugate decompositions), I included an explanation of the notation on page 3 and on page 19 of the PDF so that people who looked at that PDF could understand the notation. However, when I displayed my algorithms on the forum, I used commonly used notation.

Regarding this topic, commutator and conjugate notation come from mathematics, and I think it would be detrimental to ask the entire community to change the mathematical notation.

However, regardless of my opinion, the fact is, most people do not work with algorithms like you or I do (did), and thus it is better for us to use a notation we prefer in our "work behind the scenes" and then translate our algorithms into a notation (language) in which most people understand once we wish to share our algorithms.

Converting many algorithms into mainstream notation is not a easy task, but you (or you can ask someone else to if you don't know how) can write a program to do this for you. For example, last year I converted all algorithms on the 4x4x4 parity algorithms wiki page from Old wca to SiGN notation because Lucas Garron was recommending everyone to use alg.cubing.net instead of alg.garron.us. As you can see, there are hundreds of parity algorithms on that page, and thus there was much room for error if I would have not wrote a program to convert them all for me.