
God's Number is 20 (2010) - rishabhd
http://cube20.org/
======
protomikron
If you did not solve the Rubik cube (or did not investigate it in general), I
highly advice you to try solving it on your own. Just read _nothing_ about it.

I did it with the help of programming and it is one of the coolest problems I
solved (finding an algorithm to solve any instance).

Although I used a computer, it took me something like one or two month to
really crack it and lots of RAM to come up with a working solution.

Fun fact: My first approach (I just knew, there was this colorful cube
problem, but not that it's that hard) was a simple recursive Haskell program
where I thought I could just brute force the solution in an afternoon (I did
not know about the problem's math at that point, but looked it up afterwards)
... damn, was I wrong.

I remember that the approach involved restricting the operations (turning a
specific side) on the cube, and by allowing just 1 side to rotate one gets
len([0, pi/2, pi, 3pi/2]) == 4 solutions, but by allowing _2_ rotations the
number jumps to something like ~4*10^7 combinations already.

At that point my simple wonderful Haskell program just ate up memory, and I
had to rewrite it in another language (after first solving the 2x2x2 cube to
keep my motivation). I tried Python (very slow) and Java (which was the
fastest), but could not get rid of some GC panics, so in the end it was good
old C which found the solution by encoding one state into 24 Bytes and
building various fat, unbalanced binary trees, that provided a lookup-table
for specific phases of the algorithm.

Granted my solution was not the best, but my point is that I would not have
found it via Haskell, as I was interested in specific upper bounds to sub-
problems and being memory constrained was a nightmare with Haskell (my initial
program was nice, it type-checked and for sure terminated, but termination
required probably a Petabyte - in any case a too big number - of RAM).

~~~
WmyEE0UsWAwC2i
Being lazy evaluated, Haskell, makes it hard to reason about performance in
more than trivial code (as a rubik cube solver would be).

All those suspended computations may eat your RAM for no good reason at all.
For example:

    
    
        sum (replicate n 0)
    

has a space leak O(n). While:

    
    
        foldl' (+) 0 (replicate n 0)
    

works fine O(1) space wise.

My point is that it is easy to eat all your RAM using haskell even in the
simple `sum` case above. More so in more involved computations.

Of course, if you can compute your solution in constant space using C, you can
also do it in haskell. But writing it in Haskell would require careful thought
in how your code is evaluated.

EDIT: It is about trade offs.

If you want declarative and readabe code, with little memory layout noise
(allocate memory, assign variables, etc...) then haskell is a reasonable
choise. You can write fairly readable clode for complex algorithms. __If __you
are an expert, you can also make it efficient on the first go (speed and space
wise). If speed is of upmost importance, then you can write more compiler
specific code but with a lot of added noise.

Or you can start with C, write less (than haskell) declarative code and less
readable code. It would be harder to get right(the more complex the
computation the harder to debug), but when you are done you probably have
efficent code. If you have the experience, you may be able to make it fairly
readable too.

~~~
k_bx
I just tried this program "sum (replicate n 0)" and it didn't leak at all on
n=10000000000

Full source:
[https://gist.github.com/k-bx/4a7729bcf2386583583b95bed7d4f26...](https://gist.github.com/k-bx/4a7729bcf2386583583b95bed7d4f26c)

Also, Haskell has a nice LANGUAGE Strict pragma since recently. Won't save you
from things like lazy pairs or other imported things, of course, but at least
can be good for one-file scripts where you want to solve Rubic's cube.

~~~
WmyEE0UsWAwC2i
But if you try it on ghci you will see that it breaks. (ghc 8.0.1). So it
dependes on how you "interpret" the code. `ghc -O` is sophisticated enough to
make the right decisions when compiling your code. You probably don't want a
space leak, so it doesn't generate one.

GHC will have more trouble making the right choice in more involved
computations. It will revert to "just do what the coder says".

Consider this C code for example:

    
    
        unsigned int sum = 0;
        const unsigned int n = 1000;
        for(int i = 0; i<n; i++) {
            sum += 0;
        }
    

If you look at it, you can tell this is O(1) in space for any valid `n`. A
spohisticated enough compiler may replace it by

    
    
        unsigned int sum = 0;
    

and be done with it. But even an unsophisticated(but correct) compiler will
produce O(1) space wise code.

EDIT: format

EDIT: What I was trying to say in my original comment is that, in haskell,
space leaks my appear even in the most innocent looking code. And that it may
require a bit of experience to identify and avoid them.

~~~
k_bx
Well, sure, running code in interpreter does less optimizations than doing
full compilation. I can write an interpreter for your C code which runs out of
memory if you want :) So your "you can tell" depends on particular compiler or
interpreter implementation, and no, you can't tell what my compiler will do.

~~~
WmyEE0UsWAwC2i
I'll have to agree with that. But then I would also say that I had to make
some assumptions, right? :)

I think GHCi is helpful in this situation, however. It clearly distinguishes
between leaky and non-leaky code. This leak is a product of "just doing what
the coder says" (go to "Data.Monoid.sum" and do what it says there with such
and such...). I'm assuming that, for this code, GHCi is bug-free.

I think

    
    
        sum (replicate n 0)
    

is as dangerous as

    
    
        foldl (+) 0 (replicate n 0)
    

or

    
    
        foldr (+) 0 (replicate n 0)
    

. `sum (replicate n 0)` may be the right thing to do in some cases unknown to
me.

There is `{-# LANGUAGE Strict #-}`, as you mention, and BangPatterns for
strict arguments. But I would assume, those are used only by coders already
familiar with haskell and its leaky pitfalls.

------
mysterypie
Funny story: When the Rubik's Cube first came out, the box proudly proclaimed:
"More than 20 million combinations!"

Even in those days, it was known that it had _vastly_ more than 20 million
positions. I've wondered about the marketing guy's rationale. Obviously, "43
quintillion combinations" would not make sense to most people. But why not
write, "20 billion" or "20 trillion"? Maybe it was too discouraging.

~~~
theoh
"Even in those days"?

Douglas Hofstadter apparently published a correct analysis of the number of
configurations in Scientific American in 1981... It's not as if it was
anywhere remotely near being beyond the tools available to mathematics at the
time.

------
dorianm
Source code is in CWeb: [http://cube20.org/src/](http://cube20.org/src/)

(Can be transformed to C or to PDF:
[https://en.wikipedia.org/wiki/CWEB](https://en.wikipedia.org/wiki/CWEB))

Basically mostly written with 1 and 2 chars variable names.

BTW Finding the God Number is pretty amazing!

~~~
dom0
> Basically mostly written with 1 and 2 chars variable names.

So just your average codebase written by a mathematician? ;)

~~~
blt
sometimes, an algorithm is so intricate that it can only be understood by
reading the paper. in this case, it's much more useful to make the variable
names match the paper than to attempt semantic variable names.

------
jordigh
Wow, yet another result found by computer proof. Mathematics is getting weird.
Maybe there is some metamathematical proof that the computer proof was
produced in the correct fashion. My puny human brain wants reassurance that
this proof is correct.

It is not unheard of that widely accepted results turn out to be false. It's
rare, but it has happened. Here are some examples:

[http://mathoverflow.net/questions/35468/widely-accepted-
math...](http://mathoverflow.net/questions/35468/widely-accepted-mathematical-
results-that-were-later-shown-wrong/35558)

~~~
phamilton
I think in this case, the lower bound was theoretically proven, and now
exhaustively it has been determined that there are no positions which exceed
the theoretical lower bound. I'm pretty comfortable with that conclusion.

From what I understand, the 12 million positions that require 20 moves is not
considered definitive not completely accurate. They stated that the searches
weren't looking for the optimal solution, but rather any solution that took 20
or less moves. Without the theoretical lower bound, all the exhaustive proof
would demonstrate is that the upper bound is 20. I feel like the exhaustive
proof of establishing a given upper bound is much easier than finding the
optimal solutions for every possible position.

~~~
jordigh
And how do you know the exhaustion was done correctly? What was the process
that lead to it? Is that process correct? Could they have forgot to check some
cases? How do we know they didn't?

There are still questions pending. If you and I write bugs into our programs,
they may well have done the same thing for their program that supposedly
checks all cases.

~~~
phamilton
Isn't that the same weak point of theoretical proof? Papers get accepted, peer
reviewed, published without anyone detecting the flaw. A good example is
Hyman's mutual exclusion algorithm, which passed all the usual review without
issue but later discovered to be flawed.

The source is available and can,should be, and has been peer reviewed.

~~~
jordigh
There are just many more points of failure in a computer proof than a human
proof (I don't like calling it "theoretical", that doesn't seem like a useful
distinction, and it has connotations of not being "real" when it's opposed to
"practical"). Maybe they used numbers so big that there was an overflow. Maybe
they relied on some library that itself had bugs that didn't express itself
until they tried it on large numbers. Hell, even bits flipping due to cosmic
rays is a legitimate concern and not as far-fetched as you might think.

There are different kinds of pitfalls in computer proofs, and I wonder how can
we account for them. The errors in a computer program are far less forgiving
than the errors in a human proof. A typo in a human proof doesn't grind the
whole proof to a halt and usually the human reader can quickly mentally
correct the typo, but computer proofs are more brittle.

~~~
phamilton
Eh... A decent compiler will cause a proof to grind to a halt on a typo.

I don't really see the difference honestly, besides quantitative complexity. A
computer run exhaustive proof is less brittle than a manual exhaustive proof.
I think complexity of the proof is just a function of the length. And for a
computer proof, that length includes the toolchain.

------
grkvlt
I have a cube that I got as conference swag which they made unintentionally
harder to solve. There are two sides where the three middle pieces (number 4,
5 and 6 if you think of the arrangement of numbers on a numeric keypad) have a
logo printed across them - 'Samsung' in fact. The middle of the three pieces
is therefore constrained to be in a certain orientation (normally rotations of
that square would not matter) and therefore symmetry is broken.

So, there are four extra positions for each of the rotations of the logo
centre piece, and two of these pieces. Intuitively, it seems obvious this
makes it harder, but I'm not sure by how much. Any ideas?

~~~
jeffwass
It's almost a "supercube" :
[https://www.speedsolving.com/wiki/index.php/Supercube](https://www.speedsolving.com/wiki/index.php/Supercube)

There's some math in the regular wikipedia entry, not exactly your case but
one for all sides requiring the right rotation relative to neighbors, which
increases the state space by a factor of 4^6/2, or 2048x.

(Edit - I originally naively thought your configuration would increase the
space by 16x, but the calculation is more complicated, as some configurations
aren't attainable from a given starting arrangement without disassembly. So it
would depend on how the two labelled faces were positioned relative to each
other (ie, are they in adjacent or opposite faces), and if your definition of
a solution only requires the logos to be restored per face but not the same
orientation relative to the initial configuration.)

~~~
grkvlt
You're right, it's a partial 'supercube'. I hadn't known the correct term
before, thanks!

------
brownbat
Pretty amazing that in the quarter-turn metric, only one confirmed state
requires the full 26 moves.

[http://cube20.org/qtm/](http://cube20.org/qtm/)

------
505
At some point before 1985, an algorithm was found that could solve it in 21
"twists". (Just checked in my old copy of Hofstadter's _Metamagical Themas._ )

~~~
BurningFrog
This is not true. Back in those days the best known method needed 52 moves
(Thistlethwaite).

------
taotao670
Those interested in the field of Algebra, the Rubik's cube makes a great topic
of research. You'll learn about the Rubik's cube group and how it is a
subgroup of S_{48}. For a project I had this semester, I wanted to use
Algebraic components of the cube to come up with algorithms for solving it,
but I did not have the time.

------
uptownfunk
What is gods number for a 2x2x2 cube?

~~~
protomikron
11 (quarter and half turns) or 14 (only quarter turns). You can brute-force
that in your favorite language (there are ~3.5*10^6 configurations).

    
    
      quarter turn: +- pi/2
      half turn:    +- pi

------
ForFreedom
interesting

------
RiderOfGiraffes
Previous discussions are closed now, of course, but in case anyone is
interested in the HN thoughts and opinions, here are some links.

The result was announced some 6 years ago, and there was a long discussion
about it here:
[https://news.ycombinator.com/item?id=1587340](https://news.ycombinator.com/item?id=1587340)

It was submitted again three years ago with another lengthy discussion:
[https://news.ycombinator.com/item?id=7374994](https://news.ycombinator.com/item?id=7374994)

The other submissions had no discussion:

[https://news.ycombinator.com/item?id=3921215](https://news.ycombinator.com/item?id=3921215)
(1689 days ago)

[https://news.ycombinator.com/item?id=1606717](https://news.ycombinator.com/item?id=1606717)
(2315 days ago)

~~~
dorianm
The quality of the comments is surprisingly high: a AWS analysis, some maths,
etc.

My favorite being:

    
    
        > If you disassemble your cube and put it back together, there
        > are 12 possible sets that you can land in. Those sets are
        > not reachable from each other.
        > The proof is quite elementary.

~~~
benibela
There are even more sets if you start painting the sides

------
nocman
Hahaha -- I saw this and immediately thought it was that crazy "Timecube" guy
again! :-D

[http://timecube.2enp.com/](http://timecube.2enp.com/)

------
crypto5
Why is it "God's"?..

~~~
schoen
It's named for the idea of "God's algorithm", which is a perfect optimal
solution to a puzzle like the Rubik's cube from any position.

[https://en.wikipedia.org/wiki/God%27s_algorithm](https://en.wikipedia.org/wiki/God%27s_algorithm)

The idea of this is that an omniscient being would know the best possible move
in any configuration, and therefore might solve the puzzle in a strikingly
more efficient way than an ordinary solver.

I don't know who originated the term but, if I remember correctly, it already
appeared in Douglas Hofstadter's discussion of the Rubik's cube in the 1980s,
so it was already current then. It was a big topic of Rubik's cube research
until it was definitely solved (by the people whose work is linked above).

~~~
crypto5
Thank you. Nit: It seems like Rubik's God's number would be better naming,
because other puzzles would have different God's numbers..

~~~
schoen
True! I guess in this case the Rubik's cube enthusiasts first coined the term,
and the question was most discussed and studied in that community, so for them
the intended reference was still clear even though the concept had also been
applied to other puzzles.

------
iamtew
I'd expect it to be 23.

~~~
tajen
Why? I remember using a simple program in 2000 to see how many moves were
canonically required, and most positions I came up with were resolved in 13
moves.

On the other hand, I would have thought 19 steps were enough because they
already cover the full space of positions. To wit: There are 12 possible
choices at each step, 19 steps cover 12^19 possibilities, which is 8 times
more than the 43,000,000,000,000,000,000 positions.

~~~
schwarze_pest
> Why?

Probably: [https://s23.org/wiki/23](https://s23.org/wiki/23)

------
dtwhitney
well... I'm glad we know

