Rubik's cube without any algorithms

Question

I am learning to solve a Rubik's cube using some algorithms (I don't completely understand why they work). I had a Rubik's cube when I was little and I remember solving it 2-3 times without using any algorithms with 1-2 hours' work. Maybe it was sheer luck and some intuition. It seems very unlikely now. At that time I knew nothing about solution methods (solving layers, etc.).

Now I wonder what the chance is of solving the cube without using any algorithms and only some intuition (i.e. how difficult is it to solve it without any algorithms)?

Answer 1

This is a difficult question to answer, but it's important to clarify one point in advance: what do we mean by "algorithm"?

An algorithm, in this context, refers to a sequence of steps that you do when solving the Rubik's cube to achieve a certain outcome. It refers to any repeated sequence. For instance, there's an algorithm for moving a corner to the first layer in the cross method. There's an algorithm for flipping edges over, there's an algorithm for... you name it, there's probably an algorithm for it.

These algorithms came about largely due to intuition first. People who developed their own solutions weren't thinking in algorithmic notation - they were thinking using intuition about where they wanted pieces to move. When you're "intuitively" solving a Rubik's cube, what you're really doing is making your own algorithms from scratch, which you execute repeatedly and grow familiar with.

For instance, for a particular case on the Rubik's cube (as an example), I know intuitively to execute the sequence L' U L U2 L' U2 L2 F' L' F. I came up with this sequence intuitively on my own, and when I'm actually handling this case, I don't think about the actual algorithm notation involved - I just think about my goal. But it stands to reason that, because I do repeat this sequence, it is an algorithm. (And to be clear, this algorithm probably appears elsewhere - it's short, simple, and sweet; despite that I came up with it on my own, it's probably not original.)

So, with that basis, I'll try to answer the question of, "how long would it take to build my own set of algorithms?"

Aaand, that's a real difficult question to answer. It requires a significant number of realizations about how Rubik's cubes work that most people learn through retrospective analysis of existing algorithms. For instance, U R U' L' U R' U' L is a useful algorithm (if slightly inefficient), and by thinking about why it does what it does, we gain intuition about what we're trying to do.

Time to solve without assistance varies depending on your familiarity with a number of the pre-existing concepts. It took a month for Erno Rubik to develop a solution to his own puzzle, and it looks like it takes somewhere in the range of 10-30 hours to solve it on your own without assistance.

In other words, developing a solution is definitely tricky, but very doable, and quite possibly a worthwhile endeavor.

Answer 2

Yes, it's certainly possible, but not very easy when you've never done it before. First of all you need to have a good understanding of the puzzle itself and what everything does. What I mean by this:

When you rotate a layer 90 degrees, it does the following:

• 4-cycles four corners without changing orientation
• 4-cycles four edges without changing orientation
• rotates the center 90 degrees (which is unimportant for a regular Rubik's Cube which lacks center orientation, but is important for so-called super 3x3x3 sticker mods/shapemods)

This might look trivial, but it's important to know when solving it and to know how pieces move back and forth.

I personally haven't solved the 3x3x3 Cube on my own. But, I am a Twisty Puzzle collector and have solved other puzzles. I'm not an expert in solving if I'm completely honest, but my general approach for solving a puzzle is as follows:

• Do some random sequences until I find a sub-algorithm that does something useful. (Useful can be anything, like a double two-swap, a five-cycle, etc.)
• Then I use setup moves before or during that sequence to create other (more) useful things (usually a three-cycle or orienting some pieces without moving anything else).

These sequences (and the setup moves before / during that sequence) are combined in commutators. Commutators are generally as follows: A B A' B'. With what I've explained above, A would be the 'useful sequence', B the setup move, A' the reversed of that sequence, and B' undoing the setup moves.

For some concrete examples of some puzzles I've solved myself and how I came up with the algorithms I refer to this reply I made on the Cubers-reddit a few weeks back.

One of the puzzles I mention in the post I linked above is the Geared Mixup:

(Click for a larger image)

At one part of the solve I had to orient the gears. When I tried the following [R2 U2] (3x) I noticed it would orient every single edge-gear on the puzzle 180 degrees. So, I used some simple setup moves in between to form the following algorithm:

U'                 // 1
[R2 U2] (3x)       // 2
L                  // 3
[R2 U2] (3x)       // 4
L' U               // 5

1. This U' as setup move puts four centers at edge-positions and vice-versa.
2. When I now execute the sequence I found, these centers in edge-positions will be rotated 180 degrees instead of the edges that were in their current positions. Since centers lack orientation this doesn't matter, and the edges are safely stored at the center-positions.
3. Now I do an additional rotation with the same goal as the first U'. The reason I do two is so with the full algorithm will only rotate two gears by 180 degrees. Would I have just used the U' without this L then it would rotate four gears instead of two, which is a lot more situational and harder to setup.
4. Now I execute the sequence again to re-orient all the edges by 180 degrees again. Because two of the edges are still stored at center positions, they aren't oriented back.
5. Now I undo the setup moves to put the centers and edges back at their original positions.

The total result of the entire algorithm is that I've oriented the gears at the top back and bottom left both 180 degrees, without orienting or moving anything else (except for orienting some centers, but those lack orientation, so you don't notice this).
(It's a more advanced commutator in the form of B A C A' C' B'.)

You can also combine commutators with other commutators. This is also usually something I do. For example, usually I'm able to find a double two-swap to solve almost everything, but then end up with three pieces left to three-cycle. In that case I try to find a sequence in the same form of A B A' B' with the double-two swap and setups to create a three-cycle needed. The total algorithms usually end up very big (like 50+ moves), but it's still satisfying to be able to solve a puzzle completely on your own.

---

Sorry for the wall of text. If you've never solved a puzzle yourself it might be pretty difficult, but I know a lot of people that have been able to do it. My suggestion is to learn about commutators, then get your Rubik's Cube and a pen and pencil, and write everything useful down.

Also pick a general solving approach (which could be decided later and based on the algorithms you find). There are a lot of different methods for solving a 3x3x3 out there. Usually it's done layer-by-layer, which is probably also what you've used with the tutorial, but other approaches could be edges-first/corners-last; corners-first/edges-last; making a 2x2x2 block first; making two 1x2x3 blocks first and then solve the middle and top layer; etc. Loads of different approaches and algorithms to find.

For now I wouldn't aim for efficiency, but just for accomplishment for being able to solve it on your own.

Good luck. :)

Answer 3

Having independently worked out how to solve the cube a long long time ago, I would say it is definitely possible without a prescribed algorithm or plain luck. The only thing one really needs to understand is commutators and, speaking from experience, one does not need to be shown the idea to realise it for oneself.

Here is a question on mathematics.SE about why the approach works (thanks @user21820).

Personally I brute-forced a little to start with: I mapped out what certain sequences did looking for sequences that performed simple permutations. The more I played the more I understood this concept of commutators, for which I had no name. The method I ended up with was a layer by layer method which took quite a lot of face turns to perform (probably 100-120).

That was over twenty years ago and my method now is completely different and very similar to that of Lars Petrus' - essentially I noticed more about how the Rubik's group commutes and applied it as I went down the path of trying to minimise my moves. Note that speed solvers would also be looking for things that work quickly with their hands too while minimising difficult look ahead for commutations (some 13 move sequences may be much faster to perform than some 9 move sequences, and looking ahead would certainly slow one down).