#### emg

##### Member

I've been out of the loop for a few years, but the recent announcement on cube20.org has piqued my interest, and the first thing I want to do is write a new cube solver (I lost the code for my last one ), Thistlethwaite(-esque) at first, and hopefully a two stage/Kociemba solver later. As such I have a few questions pertaining to my quest, and a few others that I'm just plain curious about.

After a fair amount of reading I think I understand the idea behind representing the cube as coordinates (terminology from Kociemba's site, not sure if that's standard or not), using transition tables to move from one set of coordinates to the next based on the current move, and using the coordinates as indices into pruning tables. When it comes to generating these transition tables though, it's necessary to represent the cube in another way, preform a move, calculate the coordinates in the new position, and fill in the corresponding entries, right? My main questions (for now) are

1) Is it possible to perform arithmetic operations on the coordinates to represent moves, thus making some other way of representing the cube unnecessary, and making transition tables unnecessary (if you're willing to do the math instead of the lookup)? I've looked around and thought about it until my head hurts, but haven't found a definitive answer yet

2) What is the / are some generally preferred ways to represent a cube in a program? An array for permutation and one for orentation? One of each for edges and corners? Some more convoluted data structure?

And out of curiosity, has anyone found and stored full index tables for the two stages of Kociemba's algorithm (analogous to Thistlethwaite's original algorithm in which he had full tables)? Is there any point in doing that or would the penalties from dealing with such a large table make it slower than just doing IDA*?

Thanks,

-emg