# STM God's Number?



## sz35 (Aug 4, 2012)

Hey guys,
As you know, God's number is 20 ... or isn't it?
Currently, all the research was done in HTM http://www.speedsolving.com/wiki/index.php/Half_Turn_Metric
I really don't like this system for many reasons (if M is two moves because it is R L', than L is two moves because it is R M'), And prefer STM
http://www.speedsolving.com/wiki/index.php/Slice_Turn_Metric
So I thought, is God's Number smaller in STM? It probably is, but I could not find an article about it when I searched the web.
For example, in HTM it is proven that superflip cannot be done in less than 20 moves, though in STM it takes only 16.
Any thoughts/ideas?
Shai


----------



## Ranzha (Aug 4, 2012)

I wonder this too.

But L is only one move. Honestly, I think HTM should be renamed to "Face Turn Metric" permanently.


----------



## qqwref (Aug 4, 2012)

I don't think it's known. IIRC it's harder to calculate an optimal slice turn movecount than an optimal face turn movecount. It's an interesting question though.


----------



## Ked Ki (Aug 4, 2012)

I believe that they found the HTM God's number by simple exhaustion; they just ran every cube state through an optimal solver. I suppose they chose HTM as opposed to STM simply because for STM they'd have to have more turns (the slice moves) programmed in, which would have slowed the search program down considerably.


----------



## qqwref (Aug 4, 2012)

I found an 18s* state (cube20.org's "hardest position):

Solution: F E' F' D2 L2 B L E2 S2 L' U' S' D' L2 D2 S2 U F2 y x' (18s*)

EDIT: OK, according to http://cubezzz.dyndns.org/drupal/?q=node/view/200 18s* positions are relatively common (millions) so it's looking like if there are 19s* positions they are very rare.


----------



## Herbert Kociemba (Aug 4, 2012)

Ked Ki said:


> I believe that they found the HTM God's number by simple exhaustion; they just ran every cube state through an optimal solver. I suppose they chose HTM as opposed to STM simply because for STM they'd have to have more turns (the slice moves) programmed in, which would have slowed the search program down considerably.



No, running every cube state through an optimal solver will not solve the problem, at least not within your lifetime. If you really want to know more details, have a look at

http://cube20.org/
and
http://kociemba.org/performance.htm


----------

