Navigation

Who's new

Three Million Positions in Four Metrics

I optimally solved three million positions in four distinct metrics.
These positions are distinct from the three million positions I ran
some years back. Random numbers were generated with the Mersenne
Twister algorithm. The four metrics I ran were quarter-turn metric,
half-turn metric, slice-turn metric, and axial-turn metric (equivalent
to the robot-turn or simultaneous-turn metric on the 3x3 cube).
The generators for each metric are strict super- or sub-sets of the
generators for the other metrics. The quarter-turn metric has 12
generators, the half-turn metric has 18 generators, the slice-turn
metric has 27 generators, and the axial-turn metric has 45 generators.
The distance distributions for each metric were as follows:

For the last three metrics there is a single distance that is
significantly more common than any of the other distances.
This is also true for each parity of the quarter-turn metric
(where exactly half the positions are an odd distance from
solved).
We know God's Number in the first two metrics (26 and 20,
respectively). For STM and ATM, we expect God's Number to be the
same as the known lower bounds of 18 and 16, respectively.
For the quarter-turn metric, this large sample did not
encounter any positions within two of God's Number. For the
other three metrics we found positions within one of the
known or expected God's Number.
The positions we ran for all four metrics were identical, so we
can calculate correlations between the metrics.

These correlations seem surprisingly low, but this may reflect
the significant different means the different metrics attain.
These calculations were performed with my nxopt optimal solver
that supports a variety of pruning table sizes and metrics,
as well as some new techniques to speed solves. The following
table shows the average number of pattern table probes, node
evaluations, and core-seconds for each solve, using a 176GB
pruning table.

In total, on a 16-core machine, these runs took a total of 3.5
real-time days plus 8.2 hours to generate the 4 huge pruning
tables; that's an average of 39 optimal solves per second.
I will have more to say about the optimal solver in a follow-up
note.
I plan to extend my implementation of Kociemba's two-phase solver,
as well as mycoset solver to support the axial-turn metric.
Thanks to Andrew Gould for inspiring me to do this work.

16ATM positions?

What 16ATM positions are known? I made an ATM solver last year with ksolve++ but it's not really optimized enough for 3x3x3 so I could only solve a few positions. I found a few 15ATM positions but nothing more than that.

16 ATM positions

I found six 16ATM while solving symmetric states (I solved all symmetric states that are distance 20FTM and all with a symmetry reduction factor of at least 4...so...all high symmetry), and made a comment over here: http://forum.cubeman.org/?q=node/view/200#comment-3081

I didn't realize that God's N

I didn't realize that God's Number for the quarter turn metric had been determined. It has long been suspected that God's number for the quarter turn metric was 26, but I must have missed the announcement. Could you provide a link to the announcement? Much thanks.

Just an idle thought...

Why restrict yourself to 196GB pruning table if this assists greatly in your calculations, e.g. 1TB or more? .It surely wouldn't matter up front if this took a while to set up as the program wouldn't be distributed over the web for other users to run. This could be kept on a fast external HDD.

My largest machine has only 2

My largest machine has only 256GB of RAM and the pruning table must be kept in memory, otherwise access time skyrockets.

Intel's XPoint memory may help if the technology matures to the hype, but it's not quite there yet (at least not at a price point I can afford).

But absolutely, if you have 1TB of RAM, and want to solve a whole lot of random positions optimally, spend the time to generate a huge pruning table. The table generation can take advantage of many cores so it's not that slow.