• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

xyzzy

Member
Joined
Dec 24, 2015
Messages
2,465
If you were to enumerate the number of times people were confused when they saw the speedcubing form of a parity algorithm in lowercase letters versus how many people used it for reconstructions, you can't deny the possibility that it was simply more trouble than it was worth as far as confusion is concerned.
This is seriously veering off-topic (perhaps we should take this to a different thread)
Actually let me just post my reply in this here thread instead.

I don't think I've ever seen all that many people confused when I write my algs in SiGN, but I also go out of my way to minimise ambiguity whenever there's a risk of confusion (when talking about any topic, cubing or not) so maybe that's not the best yardstick.

If, for the purposes of doing patterns, you want to be able to write slice moves a bit more succinctly, then power to you if you prefer Singmaster / old WCA notation. For speedsolving purposes (cough cough look at the URL), however, there's a bit of a catch-22: nobody cares about algs because Singmaster notation sucks, and nobody cares about notation because nobody is interested in learning algs that look like crap! SiGN is how we can break out of this. This is why I'm so insistent on SiGN.

If tools like alg.cubing.net start supporting multiple notations, my fear is that, in exchange for some convenience (for a group of people largely disjoint from speedsolvers!), this introduces more ambiguity. Not on the software side (that's easy; just store everything internally in one format and convert on input/display), but in how cubers will interact with the software. Like you say, people already don't click on links; even if you provide a link to a hypothetical future version of a.c.n that supports multiple notations, it's impossible to tell at a glance what the alg is supposed to mean. Whereas now, it's basically guaranteed to be SiGN, because that's the only notation supported by the two big virtual cubes (a.c.n and CubeDB).

Maybe I'm overthinking this and it probably will be a net positive to allow different notations. It certainly would help with maintaining the parity page if the conversions are done automatically!

(Also you keep saying "old WCA notation" but like, old WCA notation doesn't have lowercase m/e/s; that's an alg.cubing.net invention. One that I disagree with, for the record. I'm sure you remember better than I do when alg.cubing.net pulled the rug out from under everyone when it suddenly changed its interpretation of the MESmes moves. (which is to say, I don't "remember" it because I don't think I was around when that happened?))

(edit: wow my memory is really failing me; the parity page doesn't use lowercase m/e/s except in the alg.cubing.net links)
 
Last edited:

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,094
Location
New Orleans, LA
YouTube
Visit Channel
(Also you keep saying "old WCA notation" but like, old WCA notation doesn't have lowercase m/e/s; that's an alg.cubing.net invention. One that I disagree with, for the record. I'm sure you remember better than I do when alg.cubing.net pulled the rug out from under everyone when it suddenly changed its interpretation of the MESmes moves. (which is to say, I don't "remember" it because I don't think I was around when that happened?))
Yeah, I remember. (I was going to mention this annoyance in the other thread, but yeah, too off-topic.) I was not a happy camper.

And I don't agree with it either, despite that I reasoned a mnemonic for explaining why Lucas did this.
Using a capital M on the 5x5x5 at alg.cubing.net turning just the central slice does make sense, if you define the M slice to be the one which actually contains the midges.

And with the nature of SiGN with the lowercase to represent multi-layer turns, there is no logical reason why both m and M parse for the 3x3x3. It makes sense if the user wants to express an algorithm on the nxnxn (n > 2) which contains turns M, E, S of all inner layers, the 3x3x3 translation won't be different than the nxnxn, but then again, if that's the case, why not keep it capital M, E, S?

I can't help but think of pages 11-21 of my Number of Permutations of the nxnxn Rubik's cube PowerPoint PDF, where we think of the 6x6x6 as an "expanded 4x4x4", for example. Where a similar idea in SiGN, the L,R,U,D,F,B slices will always contain the corner pieces of the nxnxn. Similarly, the M, E, S single/central slices will always contain the midges for the nxnxn.
 
Last edited:

EngiNerdBrian

Premium Member
Joined
Jun 21, 2018
Messages
812
Location
Denver
YouTube
Visit Channel
What methods other than basic reduction are useful for really big cubes, 13x13 and up? I am specifically wondering if there’s something other than bar building that’s beneficial for building centers? Last 2 centers can become tedious sometimes
 

Thom S.

Member
Joined
Sep 26, 2017
Messages
503
What methods other than basic reduction are useful for really big cubes, 13x13 and up? I am specifically wondering if there’s something other than bar building that’s beneficial for building centers? Last 2 centers can become tedious sometimes
There is of course Cage or K4
 
Top