# Move count metrics for big cubes - standards and preferences



## Cride5 (Aug 25, 2010)

I've been looking for a 'definitive' source on the metrics people are using to measure move counts for big cube algorithms. Unfortunately I couldn't find anything on the Wiki, and information within threads of this forum was pretty sparse to say the least. 

This post by qq here seems to cover the range of possible metrics pretty well:
http://www.speedsolving.com/forum/showthread.php?p=288422#post288422
.. but I'm not sure how standardised this sort of system is.

Just as an initial proposition (based on qq's idea) how does this sound:
* *STM* - Slice [half] Turn Metric - Same meaning as 3x3, counts half/quarter turns of a single slice (layer) as 1 move.
* *SQTM* - Slice Quarter Turn Metric - As above, but half turns count as two.
* *WTM* - Wide [half] Turn Metric - A turn of any number of contiguous layers including exactly one outer layer, by the same angle counts as one move.
* *WQTM* - Wide Quarter Turn Metric - As above, but half turns count as two.
* *BTM* - Block [half] Turn Metric - A turn of any number of contiguous layers by the same angle counts as one move.
* *BQTM* - Block Quarter Turn Metric - As above, but half turns count as two.
* *ATM* - Axial Turn Metric - Any number of turns on one axis count as one move, for example L r2 = 1 atm.

Another possible metric could exist, something between MTM and ATM. It would be like MTM but relaxing the constraints on the slices being contiguous, but requires that each slice is turned by the same angle. Although it's possible I don't think this sort of metric would be useful. What do others think, would this be useful, and for what sort of applications?

So basically, I'm looking for your opinions on creating some sort of standard for bigcube turn metrics, specifically:
* Do the metrics above make sense?
* Do they cover the range of possible applications?
* Are the names appropriate?
* What should we use as the 'standard' metric from a speedsolving perspective - BTM seems to be preferred, but is it the best at approximating algorithm execution time?


----------



## Lucas Garron (Aug 25, 2010)

Good idea; I intend to compile standards and start using them, but I'm reluctant to start on stuff like this.



Cride5 said:


> * *MTM* - Multislice [half] Turn Metric - A turn of any number of contiguous layers by the same angle counts as one move.
> * *MQTM* - Multislice Quarter Turn Metric - As above, but half turns count as two.


I suggest BSTM and BQSTM.

Does this also remind you of complexity classes?


----------



## rokicki (Aug 25, 2010)

As I start looking at the 4x4x4, I'm definitely planning to focus on BTM, so if this doesn't match what most people think as the most "interesting" metric for this size, please let me know. I think BTM is clearly the most natural metric.


----------



## Lucas Garron (Aug 25, 2010)

rokicki said:


> As I start looking at the 4x4x4, I'm definitely planning to focus on BTM, so if this doesn't match what most people think as the most "interesting" metric for this size, please let me know. I think BTM is clearly the most natural metric.


It's the most interesting because that's how you turn a physical cube most of the time.
Real slice turns –where only an inner slice moves– are possible on 4x4x4 (I use them for r2), but uncommon on big cubes in general.


----------



## Cride5 (Aug 25, 2010)

@lucas - yup, in the context of using these different metrics in a solver I can see how it sort of changes the definition/complexity of the problem, mainly by changing the branching factor.

With the choice of acronym I went for the shortest sequence of letters to describe the metric, without clashing with any other cubing related acronyms. BSTM is good from a semantics point of view, but perhaps a little too verbose?

@ rokicki + lucas ... I would deffo agree that BTM is probably best as it most accurately represents the individual turns I make when solving 4x4 with Reduction. I wonder whether K4, Roux by 4, or Sandwich users would agree tho


----------



## irontwig (Aug 25, 2010)

I guess that execution speed can probably be approximated pretty good with a (weighted) average between SQTM and BQTM.


----------



## Matt S (Aug 26, 2010)

For approximating my own speed on algs for very large cubes, I would use a combination of BTM and ATM, with the first turn on each axis counting double to account for aligning the cube.

From a theoretical perspective, I'm fond of SQTM for its mathematical properties and BTM for its physical properties.


----------



## cuBerBruce (Aug 26, 2010)

Cride5 said:


> Just as an initial proposition (based on qq's idea) how does this sound:
> * *STM* - Slice [half] Turn Metric - Same meaning as 3x3, counts half/quarter turns of a single slice (layer) as 1 move.
> * *SQTM* - Slice Quarter Turn Metric - As above, but half turns count as two.
> * *BTM* - Block [half] Turn Metric - A turn of any number of contiguous layers including exactly one outer layer, by the same angle counts as one move.
> ...



It seems like what to call various metrics on big cubes has never come to much of any agreement by people. Hence we don't really have much in the way of strong de facto standards.

I have been using "block turns" to mean moving any contiguous block of layers with respect to the rest of the cube. I am surprised it's being proposed to mean something else here. The proposal here is to use "block turns" for what was usually referred to as twists on the old cube-lovers email list. Some people have called it face turn metric (as it is always involves turning at least a face layer). The WCA regulations already defines the same metric has "half-turn metric." I really think BTM (block turn metric) is a misleading name.



Lucas Garron said:


> I suggest BSTM and BQSTM.



I think "QS" seems to imply you're allowed to move a quarter of a slice, which of course is ridiculous. I think an S between the Q and the T is bad.


----------



## mrCage (Aug 26, 2010)

BTM all the way. It's all i care about when making pattern sequences for instance. BQTM seems artificial to me:tu

Per


----------



## Kenneth (Aug 26, 2010)

I use moves like r l at times and with practice it is doable in one go, does that only fit in the axis group or is it like I think, a antislice move?


----------



## mrCage (Aug 27, 2010)

Kenneth said:


> I use moves like r l at times and with practice it is doable in one go, does that only fit in the axis group or is it like I think, a antislice move?


 
Yes, that is an "inner antislice" move. It would be 1 turn in ATM. 2 turns in BTM. No one would consider antislice moves as 1 turn on 3x3x3 so why do that on bigger cubes? Be it outer (pure) or inner ones. On cubes larger than 6x6x6 one could even have inner block antislice turns... Oh well

Per


----------



## irontwig (Aug 27, 2010)

mrCage said:


> No one would consider antislice moves as 1 turn on 3x3x3



Tony Snyder?


----------



## Stefan (Aug 27, 2010)

I thought BTM is for inner blocks as well. I like "PTM" (plane turn metric) for turing along just one plane, i.e., any number of contiguous layers including an outer layer. That name is more descriptive and thus clearer, I think.


----------



## cmhardw (Aug 27, 2010)

irontwig said:


> mrCage said:
> 
> 
> > No one would consider antislice moves as 1 turn on 3x3x3
> ...



[thread hijack]

Though I'm not sure if she would actually *count* as one move, Jessica Fridrich provides a notation that presents anti-slice turns as one unit, so possibly counted as one turn in some form of Anti-slice metric.

[/hijack]

Chris


----------



## Lucas Garron (Aug 27, 2010)

StefanPochmann said:


> I thought BTM is for inner blocks as well. I like "PTM" (plane turn metric) for turing along just one plane, i.e., any number of contiguous layers including an outer layer. That name is more descriptive and thus clearer, I think.


I can see that interpreted as "turn a single plane" where "plane" becomes a synonym for "slice."


----------



## qqwref (Aug 27, 2010)

I've always used BTM (block turn metric) to mean turning any consecutive group of slices on one axis by the same (directed) angle. I don't see any reason to change this convention now. I feel like this is the most natural metric to use because it doesn't restrict too far (pretty much anything that feels like a single move is) but also doesn't allow anything crazy to be counted as a single move (like, for instance, Axial would).

PS: For the metric where any block turn which includes an outer layer counts as one move, I suggest MTM (multislice turn metric, because of the multislice moves on cube simulators), WTM (wide-turn metric), or FTM (face turn metric).


----------



## Lucas Garron (Aug 28, 2010)

qqwref said:


> WTM (wide-turn metric)


I like this. Since SiGN seems to have lost quite a bit, establishing moves like Rw and 3Rw as "best-practice" is a good idea since it's unambiguous. Calling them all "wide turns" and using "WTM" is maybe not the most intuitive, but at least consistent.


----------



## qqwref (Aug 28, 2010)

I don't like the idea of writing Rw2 for a single turn (and then Rw2' and Rw22). Why not 2Rw?


----------



## Christopher Mowla (Aug 28, 2010)

Because it looks odd that way. Only those who are accustomed to previous notations will need to make that minor adjustment. But, I guess it could be more consistent with the inner-slice turns for bigger cubes (e.g. 2f2 is in the second portion of the 7X7X7 notation) by writing 2Rw2 instead of Rw22.

Hence, it could be 
\( \underline{\text{number of quarter turns}}\left( \text{R,L,U,F,D,B} \right)\text{w}\underline{\left( \text{ }\!\!\#\!\!\text{ of consecutive slices} \right)} \)

E.G. 2(R)w2 =2Rw2

Edit: Maybe the reason I prefer Rw22 more instead of 2Rw2 is because I used my notation in all of my research documents on odd parity algorithms (several hundred typed pages in all). Typing out Rw22 is easier on the fingers than 2Rw2, in my opinion.

Edit: Also, I prefer not to write Rw (like WCA notation) because that is only exception to the overall plane turns on big cube sizes in general (obviously). So, that's why I include the '2' there to indicate that I am moving two slices simultaneously, even though in WCA notation it is not so.


----------



## TMOY (Aug 28, 2010)

FYI, in the very first competitions where 6^3 and 7^3 were held as unofficial events, we used R_2 (with 2 as subscript) for a double layer quarter-turn, and R2 as usual for a single layer half-turn. It was really confusing and led to cubes being almost never correctly scrambled, and that's why the 2 was moved to the beginning when the events were made official.


----------



## Mike Hughey (Aug 28, 2010)

I find the current WCA notation very easy and reliable to scramble with for big cubes. It's easy to follow and quick to interpret. I'd hate to change it, for scrambling, at least.


----------



## Cride5 (Aug 28, 2010)

Lucas Garron said:


> qqwref said:
> 
> 
> > WTM (wide-turn metric)
> ...



Yup, I also like this idea ... I think it clarifies things a little. It's more obvious that a 'wide' turn needs to include an outer layer. I've edited the original post to include it as a suggestion. What do others think about it?



qqwref said:


> I don't like the idea of writing Rw2 for a single turn (and then Rw2' and Rw22). Why not 2Rw?


I've always liked the SiGN notation because it's the least verbose. Any outer turn is capitalised, while any wide turn is lower case. Only for cube sizes 6x6 and above does numerical prefix need to be used to indicate 3 or more layers. So for example (for progressively larger layer turns) a 180° turn on R would be written as:
R2, r2, 2r2, 3r2
... and so on.


----------



## qqwref (Aug 28, 2010)

cmowla said:


> Because it looks odd that way. Only those who are accustomed to previous notations will need to make that minor adjustment.


Well, yes, but it's also generally a bad decision to use two suffixes, both of which can be 2. It just gets confusing, and besides, what happens when you want to notate turning all but the left layer on a 23x23 cube? Rw22? Your notation breaks down. That's why the WCA 6x6 and 7x7 notation, and SiGN notation, all put layer depth in a prefix. Everyone who has used any cube notation at all before is used to the 2 suffix being used for a 180 degree turn, so IMO any notation that can put a 2 after the letters to mean anything but a turn of twice the normal angle is unacceptable for community use.

Cride5: You don't have to tell me how nice SiGN is, I was one of the independent inventors


----------



## mrCage (Aug 31, 2010)

For scrambling it would suffice to use solely outer blocks, just like WCA already does. For other purposes a richer notation (allowing inner blocks) would be preferable. For novices a notation like Fs can be confusing with respect to move count. F2 is 1 turn so why isn't Fs (or Fa) also 1 turn when it comes to counting:confused:

Per

I like the notation of the randelshofer applets. Some shortening is possible though. And it has some duplicates also. Overall it is very clear and works well!!


----------



## Christopher Mowla (Dec 15, 2010)

Has the general cube notation been established yet? After a little thought, I now change my position and agree with Lucas:



Lucas Garron said:


> I like this. Since SiGN seems to have lost quite a bit, establishing moves like Rw and 3Rw as "best-practice" is a good idea since it's unambiguous. Calling them all "wide turns" and using "WTM" is maybe not the most intuitive, but at least consistent.



If this is what will be standardized, then will moving, say, all middle layers on the 5x5x5 be 3M and moving the central slice still remain M?

And how about inner-layer slices? Clearly if we wish to keep Rw to mean (Rr), then we must also have r to still represent the inner-layer right slice (to be consistent with WCA). So would the inner-most right slice on the 6x6x6 (which affects the inner orbit) be represented as 2r? Obviously the reason I figure it should logically have 2 in front of it is because r has an imaginary 1 in front of it in WCA).

I would really like to have an agreement on this soon because I am going to begin to make derivation videos of parity algorithms such as "The Holy Grail".


----------



## qqwref (Dec 15, 2010)

I think it is kind of awful to have a system that uses (a) prefixes, (b) suffixes, AND (c) changes in case, together, to show what layers are turned. Besides I've always thought the w suffix was icky, since it would be the only case where letters are not used to notate turns themselves, and since using "wide" for 2 turns means you should probably use an abbreviation of "extra wide" for 3 turns, and so on. (Or "wider"?). So I don't think I would stand behind "WTM" unless I was forced to.

I don't really know what Lucas is referring to about SiGN losing "quite a bit", but I still think it's a nice consistent system even as the size of the cube gets larger. I think most people are content with a simpler system mainly because they don't need to notate things like a turn of layers 3-4 on a 7x7.


----------



## Christopher Mowla (Dec 15, 2010)

qqwref said:


> I think most people are content with a simpler system mainly because they don't need to notate things like a turn of layers 3-4 on a 7x7.


That is definitely sensible. Obviously WTM is merely an extension to the "simple notation" for larger cubes without changing how the notation applies to the 2x2x2-5x5x5 cubes.

Isn't this a good transition for those who don't want to learn an entirely different notation for larger cubes? SiGN notation makes perfect sense to me, but you and I are puzzle theorists. Since most people don't need to notate random block turns of slices (as you have said), then why should they have to explain in words how to translate algorithms to larger cubes rather than using an extension of the notation they already know very well? If we wish to use SiGN, then we can just provide a hyperlink to alg.garron.us to illustrate what we mean, but why should we make everyone else use a "harder" notation because it makes sense to us?

You have to be honest qqwref, the two notations are equally consistent in handling all of the cases for layer turning because they both have one aspect that is "unobvious". SiGN requires you use a capitol letter for a single inner-layer slice, but uses a lowercase letter for contiguous inner-layer slices, whereas WTM uses "w" for wide turns.


To everyone,
Does anyone else think SiGN is best for the overall _community_ and for _noobs_?

No matter if SiGN is chosen to be the standard notation for cubes or not, I think it should be in the wiki. I googled the notation, and the only public description of SiGN notation for big cubes I found was this thread.


----------



## Lucas Garron (Dec 15, 2010)

cmowla said:


> If SiGN is chosen to be the standard notation for cubes


It cannot be, if the WCA still contradicts it.


----------



## cmhardw (Dec 15, 2010)

I think using SiGN would be clear enough for the videos.

As for prefixes and suffixes, I personally prefer the 6x6x6 and 7x7x7 WCA notation and wish it was implemented on the 4x4 and 5x5 for WCA scrambling.

I would much rather write 2R2 on 5x5x5 than Rw2. As a side note, WCA is great for scrambling cubes, and I strongly feel that it needs to be kept around for this purpose. As a "standard" notation, though, I think WCA falls short. I would hate to describe an oblique center commutator cycle using WCA notation.

Ok so you just take your cube and do an 8 move commutator toss-up, but I'm going to write 14 moves just to be extra confusing! :
3R 2R' U 3R' 2R 2U' U 3R 2R' U' 3R' 2R 2U U'

But in SiGN this would just be:
3R U 3R' 2U' 3R U' 3R' 2U

Easy to see that's it's an 8 move commutator toss-up. So perhaps SiGN should be the "standard" notation, and WCA the "standard for scrambling" notation?


----------



## qqwref (Dec 15, 2010)

cmowla said:


> That is definitely sensible. Obviously WTM is merely an extension to the "simple notation" for larger cubes without changing how the notation applies to the 2x2x2-5x5x5 cubes.


Only if you accepted Rw on 3x3-5x5, which I never did (first it was the weird "Japanese notation", like [r] for rotations, then the WCA adopted it for some reason, but I still didn't want to use it) and which isn't all that common on the forum or in practice. It's pretty much an unofficial standard (in English-speaking communities, anyway!) to use r for a double-layer turn on 3x3. Take a look at people's posted 4x4 and 5x5 averages, too - I think most people scramble with r-type turns, rather than Rw, even though qqTimer gives you an option for either 



cmowla said:


> SiGN notation makes perfect sense to me, but you and I are puzzle theorists.


Wait, are you saying that the cubing masses *should* use a different notation than the theorists/patternists/BLDers do?



cmowla said:


> why should they have to explain in words how to translate algorithms to larger cubes rather than using an extension of the notation they already know very well? ... SiGN requires you use a capitol letter for a single inner-layer slice, but uses a lowercase letter for contiguous inner-layer slices, whereas WTM uses "w" for wide turns.


I view SiGN as a completely normal extension of the normal 3x3 notation (using r for a double layer turn, again, as I see almost everyone do). It keeps r for a double layer turn on any cube. The only new thing is the use of numbers as prefixes. To me using w for wide is as icky as using i for inverse, even though logically there is nothing really WRONG with either.



Lucas Garron said:


> [SiGN] cannot be [the standard], if the WCA still contradicts it.


The WCA doesn't "contradict" anything. It just currently uses a non-SiGN notation (actually, TWO SEPARATE non-SiGN notations), but I think the WCA would be willing to change if the community was.


----------



## Christopher Mowla (Dec 15, 2010)

qqwref said:


> Wait, are you saying that the cubing masses *should* use a different notation than the theorists/patternists/BLDers do?


No, I was trying to say that the standard notation should be a "simpler" one. If puzzle theorists wish to use other notations, they can use them, but should they provide links to virtual cube animations for others who use the standard notation to understand.

For example, if I was a vegetarian, I would not wish to give everyone else a hard time by outlawing the consumption and use of meats and dairy products. I would eat the way I wanted to eat, and if people asked me about my diet, I would take the time to explain it to them.



qqwref said:


> I view SiGN as a completely normal extension of the normal 3x3 notation (using r for a double layer turn, again, as I see almost everyone do). It keeps r for a double layer turn on any cube.


True, but some people who use that 3x3x3 notation can also view big cubes as separate because they didn't mind using WCA for them. To them, "r" is would be no different than moving all slices but L +90 degrees (if that 3x3x3 notation was translated to larger sizes). Why? Well, "r" moves the M slice. On the 5x5x5, would "r" be the 3 right-most layers or all 4 right layers? I don't think the logical assumption would initially be wide turns because a "wide" turn on the 3x3x3 is equivalent to a slice turn + a cube rotation.

Again, I have no problem using SiGN. I am just thinking about others who don't think SiGN is comfortable, considering what they have been using.


----------



## qqwref (Dec 15, 2010)

cmowla said:


> No, I was trying to say that the standard notation should be a "simpler" one. If puzzle theorists wish to use other notations, they can use them, but should they provide links to virtual cube animations for others who use the standard notation to understand.


Of course the standard notation should be simpler - it has less possible turns to cover. But it's inefficient and silly to have beginners and advanced cubers using totally different things. Fortunately the simple variant of SiGN is pretty simple to use. In fact, in scrambling it uses fewer characters than the Rw style. (SiGN's efficiency weakness is algorithms that use lots of slice moves.) 3Rw2 is quite a lot of characters for one move, and if you were using a global Rw system you'd see that type of thing a lot on 6x6 and 7x7 scrambles.



cmowla said:


> To them, "r" is would be no different than moving all slices but L +90 degrees (if that 3x3x3 notation was translated to larger sizes). Why? Well, "r" moves the M slice. On the 5x5x5, would "r" be the 3 right-most layers or all 4 right layers? I don't think the logical assumption would initially be wide turns because a "wide" turn on the 3x3x3 is equivalent to a slice turn + a cube rotation.


Are you referring to actual people? I've never seen someone take this particular approach. Anyway I find that if you explain "R moves one layer and r moves two, just like 3x3" people will get the idea very quickly. On the other hand if you explain "now that we are on 4x4 and 5x5, r suddenly means a slice turn, and Rw is the new thing for 2-layer turns" it might be a little confusing at first.


----------



## AvGalen (Dec 15, 2010)

[n]<RUFLDBrufldb>[m] for as many puzzles as possible
[n] being a number that indicates the amount of layers/slices to turn. 1 is assumed the default and can be left unwritten
<RUFLDB> being the face to turn
<rufldb> being the first slice to turn
[m] being a number that indicates the amount to turn it. 1 clockwise is assumed the default and can be left unwritten

examples:
R on 3x3x3 would be R
r' on 3x3x3 would be 2R3
M2 on 3x3x3 would be 2R2 R2 or r2
x on 3x3x3 would be 3R

turning only the 3rd slice on the right clockwise on 11x11x11 would be 2r
turning the 5th, 4th and 3rd slice on the right clockwise on 11x11x11 would be 5R 2R3
advantages:
- The same notation would work on all cubes, Pyraminx, Megaminx and several other puzzles
- Very limited amount of letters needed, no more MES, xyz, w, i
- The tiny apostrophe isn't needed anymore
- Counting moves for FMC would be easier

disadvantages:
- Spacing should be applied to avoid confusion about 2R2B meaning 2R2 R or 2R 2B 
- No way to indicate the direction of turning between M2 and M2'

I would actually like to get rid of <rufldb> for everyone except experts. Hardly anyone needs slice turns on > 3x3x3 anyway and on 3x3x3 they are not needed as shown in my example for M2.

Needing notation at all is bad enough, having 1 notation for everything we need is just overcomplicating things for everyone. [n]<RUFLDB>[m] would be good enough for 95% of the people, [n]<RUFLDBrufldb>[m] would be good enough for 99%. For the other 1%: good luck making up your own or choosing from ALL the already existing ones.


----------



## qqwref (Dec 15, 2010)

AvG: I don't think that notation is good enough for nontrivial practical use (i.e. describing algorithms and patterns). The main problems are:
- it can't describe more complex things as one move, so you can't count turns intuitively with it, without visualizing stuff or converting it (quick, how many block turns is 6R 4R2 R)
- since it's only an encoding of which layers turn in which way, it can't describe any of the nuances that are so useful in algorithms and reconstructions
- the rotation notation is really awkward (having to change the name of the rotation when the cube size changes, ugh) plus it doesn't even make intuitive sense on non-LxMxN puzzles (I do NOT want to think about a Megaminx rotation as "turn the outermost three slices on the U face clockwise")

And, of course, it's kinda inefficient (lots of characters for relatively simple stuff, spaces required) and confusing (when doing 6x6 and 7x7 scrambles I get confused between 2R and R2, 3R2 and 2R3, etc. and using 3 as a suffix would only make this worse). It's definitely one possible proposal for a general notation, but it is not the best possible proposal by any means.


----------



## cmhardw (Dec 15, 2010)

Let me ask a question in all seriousness. What do we want a standard notation for anyway? Obviously we want it to apply to at least all cube sizes.

If we want a standard notation for blindfolded solving, then the main aim is to describe single inner layer turns, and sometimes to describe large blocks of contiguous layers which may or may not include the outermost layer without too much trouble.

If we want it for describing speed-solving solutions, then we should be able to easily describe blocks of turns that are either: outer layers only, the two outermost layers together, the three outermost layer together, etc. This must also include things like turn direction, inner layer M,E,S turns, etc.

If we want it to apply well to non-cubic puzzles, then we need to take into account turn numbers, such as 3 turns for a pyraminx, 5 for a megaminx, etc.

I would argue that SiGN covers the blindfolded case pretty well, and probably also the speedsolving. WCA notation seems to cover speedsolving a bit better, with the possible issue of over-use of prefixes and suffixes that could be remedied.

Are we trying to find a notation that melds all three of these categories into one notation? Do we want a separate notation for each category? What are the goals here?


----------



## qqwref (Dec 15, 2010)

I'd like to have one notation that allows all of the following:
- writing technical algs, such as patterns and specialized commutators
- writing speedsolving algs, including the way they are performed
- efficiently writing simple algs such as scrambles, computer-generated solutions, algs for a basic solution
- a similarly full range of expression on many cubelike puzzles such as Megaminx/bigminxes, cuboids/bigcubes, Pyraminx, etc. without significant notation changes

In addition it should be concise (at least for the most common types of moves), consistent/logical, easily explained (again, at least for the most common types of moves), and easy for both humans and computers to understand.


----------



## Lucas Garron (Dec 15, 2010)

cmhardw said:


> What are the goals here?



Someone should be able to learn notation easily. Once they know it, they should be able to see an alg anywhere and know how to follow it.

Different notations become an issue when they're contradictory. "r" is the most annoying.


----------



## AvGalen (Dec 15, 2010)

qqwref said:


> AvG: I don't think that notation is good enough for nontrivial practical use (i.e. describing algorithms and patterns). The main problems are:
> - it can't describe more complex things as one move, so you can't count turns intuitively with it, without visualizing stuff or converting it (quick, how many block turns is 6R 4R2 R)
> - since it's only an encoding of which layers turn in which way, it can't describe any of the nuances that are so useful in algorithms and reconstructions
> - the rotation notation is really awkward (having to change the name of the rotation when the cube size changes, ugh) plus it doesn't even make intuitive sense on non-LxMxN puzzles (I do NOT want to think about a Megaminx rotation as "turn the outermost three slices on the U face clockwise")
> ...


 
Later you said you wanted one notation to rule them all. That is great for experts like you and a few dozen others in this community, but it is horrible for all others. I agree that my notation is not good for nontrivial things. But that is not what it is meant for. I explicitly said so in my post, so there is no need to discuss that at all.

-Yet then you go on describing that it can't describe more complex things as one move without providing any example for it?
-Counting moves (assuming HTM) would be as simple as counting everything that doesn't start with the number for the cubesize (assuming the extreme of not allowing <furbdl> and that it makes counting turns unintuitively.
-I already mentioned that it doesn't allow to describe the distinction between M2 and M2', yet you repeat that as well
-And the rotation notation is actually elegant in my view. No extra letters or characters needed and for me it is very intuitive. Rotate a 5x5x5? 5R! Rotate a 11x11x11? 11R!

"quick, how many block turns is 6R 4R2 R"?
What is a block turn? Obviously it is 3 turns in HTM


----------



## qqwref (Dec 15, 2010)

AvGalen said:


> Later you said you wanted one notation to rule them all. That is great for experts like you and a few dozen others in this community, but it is horrible for all others. I agree that my notation is not good for nontrivial things. But that is not what it is meant for. I explicitly said so in my post, so there is no need to discuss that at all.


Of course there is a need to discuss it. Looking from the point of view of a beginner, a notation should be simple, and then have simple *extensions* to deal with more complicated things. You offer no extensions and in fact explicitly say that anyone who wants anything more complicated has no business using the standard notation at all. That is ridiculous.



AvGalen said:


> -Yet then you go on describing that it can't describe more complex things as one move without providing any example for it?
> -Counting moves (assuming HTM) would be as simple as counting everything that doesn't start with the number for the cubesize (assuming the extreme of not allowing <furbdl> and that it makes counting turns unintuitively.
> -I already mentioned that it doesn't allow to describe the distinction between M2 and M2', yet you repeat that as well
> -And the rotation notation is actually elegant in my view. No extra letters or characters needed and for me it is very intuitive. Rotate a 5x5x5? 5R! Rotate a 11x11x11? 11R!


-I don't need to provide an example, because you've already shown all possible move types. But here: turn the 2nd and 3rd layers (from R) of the 5x5 clockwise.
-HTM (do you mean multislice turn metric?) for bigcubes is NOT the only metric worth talking about, but your notation is explicitly based around that type of move. Counting moves in any other metric is not straightforward, just like getting an STM count for 3x3 moves written in FRUBLD only. If you decide to completely disallow MESxyz, you're actually making things more confusing for any non-basic use of notation.
-Yes, I repeated the inability to express more complex turning because it is an important and significant downside to your system. Maybe you only deal with teaching new people who will never try to get under 20 seconds, but the speedcubing community has a lot of people who want to optimize their solves.
-Uh huh. But now any sequence with rotations cannot be performed on a bigger cube without being rewritten. You can't do "3R R3 U R3 D2 R U3 R3 D2 R2 3R3" - that's an A perm, by the way, see how ugly it is now - on a 5x5 without changing some of the numbers. With the current style, many algorithms can be used on any size of cube. Some algorithms (like Sune if you write it as R U R' U R U2' R') can even be used on Megaminx or Pyraminx with no rewriting at all.



AvGalen said:


> "quick, how many block turns is 6R 4R2 R"?
> What is a block turn? Obviously it is 3 turns in HTM


Why are you putting effort into showing your ignorance?


----------



## reThinking the Cube (Dec 23, 2010)

qqwref said:


> Why are you putting effort into showing your ignorance?



Why did you put effort into showing your ignorant boot stomping of a friendly puppy?


----------



## qqwref (Dec 23, 2010)

...what?


----------

