[Feature request] add slices to NxNs larger than 3x3

[trexrush]

Goal

Hi, Id like to be able to use M, E, and S slices on big cubes. Im currently using puzzleGen (refactored typescript visualcube) on a project alongside cubingjs, and I cannot apply the same algorithm on 4x4 for both which means I need to add a notation translator function to use M slices (as well as inner slices)

Quick comparison of notation between these packages:

// Preferred    PuzzleGen   Cubingjs|   changes
// ________________________________ | __________
// r            r           2R      |   fine
// Rw           Rw           Rw     |   no change
// M            M           2-3r'   |   this issue
// 3Rw          3Rw         3Rw     |   no change

Possible solution

implement the moves or alias them for the existing notation (M' => 2-3r)

Alternatives

a way to define custom notation in a project specific manner to avoid having to hardcode extra notation, though that goes against the contribution guidelines of putting extra work on the user.

[lgarron]

cubing.js supports the same big cube slice moves as alg.cubing.net :

https://alpha.twizzle.net/edit/?alg=R+L+U+D+B+F+%2F%2F+Single+moves%2C+variable+spacing.%0AB%27+F%27+D%27+U%27+L%27+R%27+%2F%2F+Inverses.%0AR+L2+R3+L2%27+R5+L8%27+R7+%2F%2F+Move+amount%0AU+.+U+.+U+.+.+.+U+%2F%2F+Pauses.%0AM%27+E2+S2+M+S2+E2+m2+e2+s2+m2+e2+s2+%2F%2F+Slice+turns.%0AM2%27+U%27+M2%27+U2%27+M2%27+U%27+M2%27+%2F%2F+H%27perm.%0Ax+y+z+%2F%2F+Rotations.%0AR2+L2+R2%27+L2%27+%2F%2F+Half+turns.%0ARw+r%27+Lw+l%27+Uw+u%27+Dw+d%27+Bw+b%27+Fw+f%27+%2F%2F+Wide+turns.%0A4Rw+x+L%27+%2F%2F+Very+wide+turns%0A2-3Lw+3-4r+%2F%2F+Wide+block+turns%0A%5B%5BR%3A+U%5D%2C+D2%5D+%2F%2F+commutator%2Fconjugate%2Fnesting%0A%5BR%3A+U%27%5D+D22%27+%5BR%3A+U2%5D+%2F%2F+Grouping+and+repetition&setup-alg=M2+U+M2+U2+M2+U+M2&puzzle=5x5x5&title=Notation+Demo

I suppose your concern is that you expect M2 to act like m2? That's something we might consider for Twizzle alpha in response to feedback, but not something we'd revisit particularly soon. Would you be able to accommodate that in your code?

[trexrush]

hi! I think the only confusing aspect in terms of understandability is having M refer to the inner slice move and m refer to the wide slice move. Furthermore, due to how M is defined, it is an invalid move on even layered big cubes.

I think my use case will require some form of adapter to accommodate multiple notations for external tools, so I can work around this for now.

I still think there is a good reason to allow users to define aliases for move notations, like I suggest in the alternatives section. This could allow an in-library way of substituting custom notation, immediate use cases would be for things like implementing Karnaukh notation / karnotation on square-1, or overriding big cube notation to better fit existing and common algorithm patterns, such as r / 2R instead of 2-3R on 6x6 (or M for big cubes as was my need)

That being said, the initial request was made mostly because of me not finding the proper documentation or code for valid move types. I think there is a valid suggestion here, however, though since my immediate use case doesn't require any code change it would be low priority.