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:
(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:
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
 
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
 
I know nothing about k4 but have heard of the cage method. I’ll have to look up some tutorials for those methods.

What are the high level pros/cons of each method?
I can't tell you much about K4 but cage is kind of nice if you want to get edges out of the way quickly, however I don't think that its nearly as good as redux since it makes whats already the easier part (on cubes that large) easier, and the hardest part harder.
 
I can't tell you much about K4 but cage is kind of nice if you want to get edges out of the way quickly, however I don't think that its nearly as good as redux since it makes whats already the easier part (on cubes that large) easier, and the hardest part harder.
I agree. I played around with cage this weekend and it seemed definitely worse for big big cubes since building centers is much more restricted.
 
Any tips to setup a 6x6. My MGC is slow for some reason.
The stiffest springs, light lube (I use Silk, DNM-37 should be OK), and fiddle with the tensions. The MGC is generally a pretty fast cube, I've run across a few cubes that just seem to be slow for no particular reason, and I haven't had much luck speeding them up.
 
The stiffest springs, light lube (I use Silk, DNM-37 should be OK), and fiddle with the tensions. The MGC is generally a pretty fast cube, I've run across a few cubes that just seem to be slow for no particular reason, and I haven't had much luck speeding them up.
I thought all the springs were the same so I'll change them
 
Back
Top