[i:1lu2cdmx]12b) Rotations for all puzzles: # 12b1) Clockwise, 90 degrees: [f] or z, [ b] or z', [b:1lu2cdmx][r] or x', [l] or x[/b:1lu2cdmx], [u] or y, [d] or y'. (see 12a1). # 12b2) Counter clockwise, 90 degrees: [f'] or z', [b'] or z, [b:1lu2cdmx][r'] or x, [l'] or x',[/b:1lu2cdmx] [u'] or y', [d'] or y (see 12b1).[/i:1lu2cdmx] I have always been under the impression that the x rotation of the cube followed the R face. From what I read here is totally opposite. I even get the impression from Dan's site that the x rotation is now changed: http://www.cubestation.co.uk/cubenotation.html Also from speedcubing.com it looks opposite: http://speedcubing.com/peter Am I reading it wrong or has it changed?

[quote="Henrik":2rxsej0p]Am I reading it wrong or has it changed?[/quote:2rxsej0p] It's just a mistake, thanks for detecting it.

Ok thats nice I was getting worried. But you are welcome

How about an article about the notation of Clock?

[quote:3tntgfwa]12a4) Counter clockwise, 180 degrees: F'2, B'2, R'2, L'2, U'2, D'2 (see 12a1).[/quote:3tntgfwa] Redundant?

Hi Henrik, Thanks for your sharp eye. It should be correct now. [version March 19] I do not think that moves likes U'2 are redundant. They are used by some people when showing finger tricks. Ron

This article doesn't seem to define how to write sequences of more than one move. Should it be RUR' or R U R' or something else? And it's very repetitive, I think using a BNF-like language would be much better. [i:3nyh7x6y]12b) Rotations for all puzzles:[/i:3nyh7x6y] I don't see how this is general enough to work for all puzzles.

[quote:1wb714g7]I don't see how this is general enough to work for all puzzles[/quote:1wb714g7] I changed it to cube shaped puzzles. I am not sure we need it for other puzzles (yet). Updated in version draft 4a, March 21, 2008. Thanks, Ron

[quote="Ron":37gec8a0][quote:37gec8a0]12c - Does this mean there will be no more scrabmles starting with a slice turn?[/quote:37gec8a0] Only for puzzles 6x6, 7x7 and so on. Hopefully next year![/quote:37gec8a0] My question referred to the square-1 scrambler. The wording of 12c suggests that slice turns only come after a set of rotations, yet the scrambler still can give scrambles that start with a slice turn. -Chris Krueger

Ah, so with 'slice turn' you mean the half turn of the right side of the puzzle. Indeed scrambles cannot start with a half turn of the right side of the puzzle. If you would need that in a normal move, then you could write (0,0)

Okay, sorry for the confusion, I don't actually know the terminology for square-1. The current scrambler doesn't reflect this notation. -Chris Krueger

[quote:3h8eqxlj]The current scrambler doesn't reflect this notation[/quote:3h8eqxlj] You are right. Updated in version draft 4b, March 22, 2008 Thanks, Ron

Whole cube rotations: It is good to standardize notation as is suggested. However I believe we should narrow the choices. x / y / z should remain as it is a widely adopted notation. [r] / [u] / [f] is a great alternative for those who don't like x/y/z and square brackets differentiate finger trick combos and optional moves in algs from cube rotations, which is excellent. I do feel that the [l] / [d] / [b} variation is redundant and will make things less standardized. I believe this variation should not be officially suported. I feel we should discard [l] / [d] / [b} in favour of only using [r] / [u] / [f] or x / y / z for a couple of reasons: 1) it is an extra variation which will lead to inconsistencies among algs listed even among those who chose not to use x / y / z. We should strive to keep everyone on the same page. 2) {l] / [d] / [b:11aobqyr] uses opposite turn notation for the same move that would be listed in x / y / z or [r] / [u] / [f] leading to inconsistencies and possible transcription errors when changing from one notation to another. e.g. x = [r] = [l[b]'[/b:11aobqyr]] | y = [u] = [d[b:11aobqyr]'[/b:11aobqyr]] | z = [f] = [b[b:11aobqyr]'[/b:11aobqyr]] We should only use the notation that keeps clockwise/counter-clockwise notation the same for both methods of notation.

Another proposed change: In the section that mentions that rotations of the entire cube (x / y / z) should not be counted as a move... I believe an clause should be added that states it will be considered a move ONLY in the FEWEST MOVES competitions. Understanding algorithm variations that do not include a cube rotation, is an advantage an experienced Fewest Moves competitor might have over someone less experienced. We should reward the competitor who understands the extra algs and calculations necessary to complete the Fewest Moves competition by counting rotations of the entire cube as a move in this specific event. In all other events, I believe x / y / z should not be counted as a move.

[quote="VooX":x4yt8m7a]Whole cube rotations: It is good to standardize notation as is suggested. However I believe we should narrow the choices. x / y / z should remain as it is a widely adopted notation. [r] / [u] / [f] is a great alternative for those who don't like x/y/z and square brackets differentiate finger trick combos and optional moves in algs from cube rotations, which is excellent. I do feel that the [l] / [d] / {b} variation is redundant and will make things less standardized. I believe this variation should not be officially suported. I feel we should discard [l] / [d] / {b} in favour of only using [r] / [u] / [f] or x / y / z for a couple of reasons: 1) it is an extra variation which will lead to inconsistencies among algs listed even among those who chose not to use x / y / z. We should strive to keep everyone on the same page. 2) [l] / [d] / {b} uses opposite turn notation for the same move that would be listed in x / y / z or [r] / [u] / [f] leading to inconsistencies and possible transcription errors when changing from one notation to another. e.g. x = [r] = [l[b:x4yt8m7a]'[/b:x4yt8m7a]] | y = [u] = [d[b:x4yt8m7a]'[/b:x4yt8m7a]] | z = [f] = {b[b:x4yt8m7a]'[/b:x4yt8m7a]} We should only use the notation that keeps clockwise/counter-clockwise notation the same for both methods of notation.[/quote:x4yt8m7a] [size=150:x4yt8m7a]Looking at my above post the notation {b} with square brackets also plays havoc with HTML commands (being the command for BOLD text) this leads to very blatant errors, as my quoted (and corrected) post shows compared to the original which dropped all the {b} notations thinking I was giving the BOLD command![/size:x4yt8m7a]

Is no one else concerned about the incompatibilty of the ["b"] notation with html language? I still feel that l/d/b for whole cube turns should be excluded from the official notation in favour of r/u/f and x/y/z. It keeps the clockwise/counter-clockwise notation the same, and eliminates the perpetual errors of the bold command when posting algs to the internet.

1. That is BBCode, [b:mqjtnava]not[/b:mqjtnava] HTML. 2. Use the Preview button.