I've submitted [url:r1mifqqf]http://cube.garron.us/WCA/proposals/square1_raphael/scramble_square1_mrss.htm[/url:r1mifqqf] to the WCA board for consideration. I thought I'd also post it here, in case anyone else has comments. Here's my email to the WCA board: [quote:r1mifqqf]Hi there, I'd like to (strongly) recommend that we adopt the following scrambler: http://cube.garron.us/WCA/proposals/squ ... 1_mrss.htm How All the relevant files can be downloaded in a zip from: https://github.com/lgarron/sq1.js If you choose to adopt this, it should be a simple matter of uploading all these files to the same folder somewhere. Why In order to make this as easy and beneficial to adopt as possible, it has a few useful features, including: - It resembles the old scrambler, even retaining support for things like changing color scheme. - True random-state scrambles (including middle slice), using a better-quality random number library. - Better images, which look cleaner and e.g. don't cause as much trouble when exporting to PDF. - / turns are displayed in the algorithm again, to e.g. fix ambiguities that used to occur at the end of the scramble. - In case it is a concern that this scrambler is too slow in some circumstances, there is still an option for "old" scrambles. The number of turns for the old style scrambles has been increased to 60 moves 1) discourage its use, and 2) to provide a little more randomness. My recommendation is to allow this to be used for official scrambles only for a few weeks, if at all. Compatibility This scrambler should be able to generate 5 scrambles in a reasonable time on a reasonable computer with a good browser. It runs in <1min most of the time (closer to 10 seconds for me), which I think is reasonable to do once per competition for the increased benefit of much beter scrambles. - Google Chrome currently handles it best. - It also runs fine in Opera and Safari for me, albeit a little slower (still < 1min). - Firefox tends to become unresponsive during complex scripts, but it also finishes in <1min and becomes responsive again. - No attempt has been made at IE compatibility. It is not easy for me to test on IE right now, and IE compatibility is notoriously annoying to handle. The source code is public, in case anyone wants to fix that. However, I think that support in all the other major browser should be enough for any competition organizer to be able to use it. Credit I put a lot of effort into this port, but it's not all my work. In particular, the core of the scrambler is from Walter Souza's Prisma Puzzle timer (with his permission). Full credits, in chronological order: - Jaap Scherphuis: The original scrambler, which the HTML is still based on. - Andrew Nelson and Michael Gottlieb: The original Square-1 drawing code. - Waltter Souza: Square-1 random-state generator and solver, from Prisma Puzzle Timer. - Lucas Garron: Javascript updates to the drawing, and random-state code port/extension. Libraries: - raphael.js: SVG drawing. - mersennetwister.js: Random number generation. Future I'm currently working on a more unified system for all the scramblers (including 3x3x3 random-state scrambles in the browser using QBX by Evan Gates), but I thought I'd submit this for now. Sincerely, »Lucas Garron[/quote:r1mifqqf]

I strongly agree with this proposal. The relatively common occurrence of 'stupid' easy scrambles for Sq-1 has been widely reported, so it is certainly time for this new Markov random-state scrambler to be introduced. The program ran fine for me, and the new graphics are good too. Thanks Lucas

Fantastic! I support this 100%

Sorry to double-post, but I think this response deserves a second look. After using this scrambler in practice for two weeks, I can see a clear pattern in the scrambles. The scrambles keep the puzzle in cube shape for most of the length of the scramble, only leaving that shape near the end. At first look, this seems like a useful pattern. The scrambles are fast and easy to perform, and it is more difficult to make a small error in the first section of the scramble. However, my concern is that the overall parity of the puzzle can be quite often determined from the scramble alone. Parity cannot be affected in any shape less than 3 twists away from square/square, and so any scramble that does not pass through one of these shapes will not have parity. Similarly, if a scramble passes through one of these shapes, then returns to a shape closer to square/square, it will quite obviously have parity in the end. Scrambles that end up in a shape in which parity can be affected (or at least, a shape that requires you to pass through one of these shapes on the way to square/square) may have parity depending on the way they are solved, but even then when scrambling for myself I can solve the shape in a way to avoid parity altogether. As an example, take a look at these scrambles: (-3, -1) / (-3, 0) / (-2, 1) / (-1, 5) / (-3, 0) / (0, 3) / (0, -3) / (0, -2) / (0, -3) / (-2, -1) / (-3, 4) In this scramble, the puzzle remains in cube shape until the (0, -2) near the end. It then goes through three other shapes, none of which can affect the parity of the puzzle. Thus, just by looking at the scramble, even without a puzzle in-hand, I can clearly determine that the resulting position has an even parity. (0, -1) / (-2, 1) / (-3, 0) / (5, -1) / (0, 3) / (0, -3) / (1, -2) / (0, -3) / (5, 0) / (0, -3) / (-2, 5) / (-4, 4) / (-4, 4) / (6, 0) In this scramble, every move before (5, 0) keeps the puzzle within cube shape. The puzzle then goes to a paw/paw shape, and the second to last / move changes the parity, before bringing the puzzle back to fist/fist (where parity cannot be affected). By knowing this parity ahead of time, a solver could quite easily solve the shape in an otherwise ridiculously inefficient manner, negating parity in the first step of the solve. Now, this obviously doesn't matter much in an optimal competition environment, as no solver should be able to see the scrambles, nor watch their own puzzle being scrambled. I don't think that this invalidates the entire program. This scrambler is quite clearly a great deal better than our current one. I'm not even sure if this issue matters at all, but I feel it's worth bringing up, as no other scrambler (except perhaps clock) allows you to gain information about the puzzle's state by quickly looking at the scramble.

Thanks for your thorough post, Andrew. Sorry for not replying to this here earlier, but I'm currently having a bit of trouble logging into this forum, and you and I have discussed this over chat a bit. First, I'd like to note that this isn't entirely specific to Square-1: It is approximately as easy to tell permutation parity from a 3x3x3 scramble, which can provide additional confidence for BLD memorization. The same issue also occurs for 2x2x2 scrambles that can be seen to be short scrambles at a glance (and there hasn't been a conclusive ruling on whether random-state 2x2x2 scrambles should have a minimum length). In addition, <R, U, F> scramblers leave the DBL corner unchanged. Anyhow, I think this is not really an issue for scramblers in competitions. Parity not *immediate* from a glance at a regular scramble. In addition, scrambles should be thoroughly obscured from competitors, and one of the WRC topics for 2012 is a requirement for this to be followed more thoroughly.