State of computer solving

[hawkmp4]

So I'm beginning work on a computer solver that will be targeted at the megaminx (though it will be general-purpose). I've been away from speedcubing for quite some time- I was last really active in 2011. It seems ksolve has been inactive for ~2 years according to the Github repo (https://github.com/cubing/ksolve). Has there been any development past that?

My goal is to be able to generate algorithms for megaminx LL cases using as large of a generating group as possible. Given that my calculations set a full pruning table for <R, U> at roughly 7 petabytes, this will be a challenge. Has there been any big projects specifically targeted at megaminx? I have some good ideas about how to proceed but I don't want to reinvent the wheel (if it's been invented yet!)

 

[unsolved]

I have fast solvers for 4x4x4 and 5x5x5 cubes, but not Megamix. I don't take the approach of pruning for the sake of generating move reduction though. I make use of 3 different hash tables for the 5x5x5 and get search speeds of 97,033,741,814,062 nodes/second (97 trillion).

 

[qqwref]

Well, good luck making a megaminx solver, haha...

Given that my calculations set a full pruning table for <R, U> at roughly 7 petabytes, this will be a challenge.

Mm, but you could do just corners or just edges. There are 44 million positions for corners in <R,U>, and 181440 for edges.

Or, in <R,U,L> there are 3.1 billion edge positions and 1.1 trillion corner positions; in <R,U,F> there are 490 billion edge positions and 53.5 billion corner positions. Maybe some of that will end up doable.

 

[cuBerBruce]

There are less than 8*(10^12) elements in <R, U> so even at one byte per element, a full breadth-first search of <R, U> doesn't require more than 8 terabytes for the table. (7,999,675,084,800 to be exact.) That's still too large to be practical for a pruning table, so use a subset of pieces as mentioned by qqwref.