Cubetimer?

[signaly]

How exactly does cube timer get their scrambles? I mean is it just a random set of moves or is it something more specific?

 

[brunson]

Cubetimer.com? I believe they generate random sets of moves with some constraints to keep small sets of moves from undoing themselves.

 

[Johannes91]

Just a random sequence of moves, if I'm reading it correctly. Using a 3x3x3 solver and random position isn't easy in JavaScript.

 

[signaly]

Okay that makes sense but what about 180 degree turns wouldn't they undo themselves?

 

[Johannes91]

There are just two kinds of cancellations that scramble generators need to forbid: U U and U D U. Whether the turn is 90 or 180 degrees doesn't matter, just the face.

 

[signaly]

Oh, I see, thanks.

 

[Stefan]

Using a 3x3x3 solver and random position isn't easy in JavaScript.

Is it easier in other languages? If so, which and why? Or I should directly ask why it's not easy in JavaScript, because I know other languages but JavaScript not really. So does it have significant disadvantages?

 

[Johannes91]

Using a 3x3x3 solver and random position isn't easy in JavaScript.

Is it easier in other languages? If so, which and why? Or I should directly ask why it's not easy in JavaScript, because I know other languages but JavaScript not really. So does it have significant disadvantages?

I tried to write a solver that's reasonably fast and doesn't use too many moves a while ago, but gave up. I couldn't even get Thistlethwaite's algorithm working decently. Then I tried Haskell, and found it quite easy to implement Kociemba's algorithm and to make it find solutions shorter than 25 moves in less than a second. JavaScript is in my opinion more difficult, because:

* there are no native types, so tables take much more space than they need to;
* it's a very slow language, so without big tables the solver will be slow;
* if JavaScript code takes too long to finish, some browsers will freeze and/or terminate it.

There are many different implementations, of course, and the above points might not be true for all of them. I used SpiderMonkey for testing. And I'm far from an expert at JavaScript, it's very possible that I was just doing something stupid.

That said, it would be possible to connect to a server-side solver.

 

[cubetimer]

CubeTimer randomly picks a face on each iteration through a loop of the desired number of turns, but there are restrictions:

• Each time a face is turned, the possibility that the same face is selected for turning on a future iteration is disabled
• Once a face is disabled, it will not be turned again until enabled by the turning of an intersecting face

As far as I can figure, there is no chance for a move, or even a series of moves to undo itself. The one thing I'm not real happy with and will probably change soon is that a face does allow an opposite face to still be selected for turning. This is fine for something like U D, because they are in opposite directions, but in cases like U2 D2 or U D', it's the equivalent of just turning the equator.

There are no cases where moves will cancel each other out, but this case takes 2 turns to do the equivalent of one, which means you aren't REALLY getting a full 25 turns, sometimes.

 

[mrbiggs]

As far as I can figure, there is no chance for a move, or even a series of moves to undo itself.

A series of moves can, like (R U' R' U) x 6 or (R2 U2) x 6, unless I'm misunderstanding the algorithm.

 

[cubetimer]

No, you're right, but I figured cases like that were pretty low odds and chose not to worry about them...

 

[joey]

Every series of moves undoes itself, eventually.

 

[benjediman]

Speaking of Cubetimer, when I use 2x2, I get scrambles with opposite face turns right next to each other like D2 U2. Shouldn't the 2x2 have a different set of scrambles, like Jnet that avoids that when I select 2x2?

 

[Stefan]

Thanks Johannes, I didn't know about those JavaScript drawbacks. They really sound bad, and if you even had trouble with Thistlethwaite... I had thought about doing that myself, thought it should be easy. I've read a JavaScript article recently where the author emphasized that JavaScript is a regular programming language and not just a browser toy. That might've given me a wrong impression.

Every series of moves undoes itself, eventually.

No, only those which are called "algorithm", of course, by defination!!!!!!!!

this case takes 2 turns to do the equivalent of one, which means you aren't REALLY getting a full 25 turns, sometimes.

You *are* getting 25 turns in HTM. And that's where the 25 recommendation/requirement comes from.

 

[cubetimer]

Speaking of Cubetimer, when I use 2x2, I get scrambles with opposite face turns right next to each other like D2 U2. Shouldn't the 2x2 have a different set of scrambles, like Jnet that avoids that when I select 2x2?

Good catch - I never thought of that. I've never actually used CubeTimer for my 2x2 as I don't play with it much...

I'll get that changed as soon as I get a chance to do so.

 

[cubetimer]

Thanks Johannes, I didn't know about those JavaScript drawbacks. They really sound bad, and if you even had trouble with Thistlethwaite... I had thought about doing that myself, thought it should be easy. I've read a JavaScript article recently where the author emphasized that JavaScript is a regular programming language and not just a browser toy. That might've given me a wrong impression.

Personally I would tend to agree more with the article you read. JavaScript has it's drawbacks for sure. It's no competitor for a compiled language, but it can do far more than a lot of people give it credit for. JS used to be a bad word among web developers, but it's responsible for most of the Web 2.0 stuff you see floating around out there today. If it's good enough to create things like Gmail and Google Maps, I think it deserves a bit of credit...

Every series of moves undoes itself, eventually.

No, only those which are called "algorithm", of course, by defination!!!!!!!!

There is, of course, the chance that the scramble will come up with an algorithm repeated enough times for it to cancel itself out. There is also a chance that it will give you the exact same algorithm 20 times in a row, but neither scenario seems likely...

this case takes 2 turns to do the equivalent of one, which means you aren't REALLY getting a full 25 turns, sometimes.

You *are* getting 25 turns in HTM. And that's where the 25 recommendation/requirement comes from.

You're saying it does meet requirements as is? I wasn't sure if it was better to leave it the way it is or change it to include turns of middle layers...

 

[brunson]

Speaking of Cubetimer, when I use 2x2, I get scrambles with opposite face turns right next to each other like D2 U2. Shouldn't the 2x2 have a different set of scrambles, like Jnet that avoids that when I select 2x2?

Good catch - I never thought of that. I've never actually used CubeTimer for my 2x2 as I don't play with it much...

I'll get that changed as soon as I get a chance to do so.

The scrambler that I wrote I got around it by not selecting a random face, but selecting a random axis, then choosing one of the faces on that axis, then a turn. I.e. Pick one of x, y or z, if you pick x, then pick R or L, if y, then U or D, z implies F|B, finally, pick the turn of 1, 2 or -1. All you have to do is ensure that you don't pick the same axis twice in a row and you eliminate the scenario benjediman describes.

 

[Stefan]

You're saying it does meet requirements as is?

Yep. geadfsfdfgsdrandomstufftoreachtherequiredtencharactersverystupidrule.

 

[Johannes91]

Yep. geadfsfdfgsdrandomstufftoreachtherequiredtencharactersverystupidrule.

Heh.

 

[FU]

You're saying it does meet requirements as is?

Yep. geadfsfdfgsdrandomstufftoreachtherequiredtencharactersverystupidrule.

...