I came up with 6513 using a program that I wrote. I used an iterative-deepening depth-first search up to depth 9 (all combinations of 9 twists).

Can you post the code?

I have the code available online, and it has been heavily peer reviewed (github.com/benbotto/rubiks-cube-cracker), but extracting the code that I used to come up with the 6513 number would be difficult due to the amount of code involved (the search code, the pattern database, the rubik's cube models, etc.). In that repository, I've implemented Korf's optimal solver (God's algorithm), and Thistlethwaite's algorithm, and both work well. I'm working on an improvement to the latter, though, and I'm struggling with this part of the math.

I added a few code snippets above, for what it's worth. As far as searching, I basically just iterate through all possible combinations of moves and count the number of unique permutations (github.com/benbotto/rubiks-cube-cracker/blob/master/Control‌​ler/…).

For such a large group I'd be surprised to see a God's number, a search depth, of 9.

God's number is 20. I use Korf's algorithm for that.

Also, the 6,513 corner position orientations I mentioned are reachable in 6 twists. For all orientations of the corner pieces, the 2187 states are reachable in 7 twists. All corner arrangements and permutations (8! * 3^7) can be reached in 11 or fewer moves.

Why are you using a search depth of 9? It might make sense to rerun at a search depth of 11.

Ah, yes, sorry I misunderstood the God's number bit.

In the search I'm using I'm not doing any pruning other than obvious trivial pruning of redundant and commutative moves, like {L L'}, {L L2}, {L R} (which is the same a {R, L}), etc. So, the branching factor is roughly 13, and it takes a long time to iterate to depth 9. In roughly 5 hours I will have iterated through depth 10. Put another way, my program just hasn't finished depth 10 yet.

Hey SpaceDisgrace. Thank you for your help.

No problem. I like puzzle cubes.

Hah! Same here, if you can't tell from the repo I posted.

So if you hold the cube fixed with orange on top, red on bottom, and only consider the sides for moves

you have four possible moves

Mind if we use the convention white up top, red up front?

That's just the orientation I picked in my program.

yeah

I'm using the quarter turn metric

so only 90 degree turns count

Okay.

My program counts double moves as 1 turn, but no biggy.

It might affect it

I know the God's number comes out different

depending on what counts as a turn

Right.

So whenever I make one move I disorient some number of cubes

Yeah, and the number disoriented is always 0 or 6, right?

I.e. none disoritented, or two disoriented by 1, and two disoriented by 2.

If the cube is starting from a solved state

I'm playing with my mixed up cube now.

If I make a single move I disorient some cubes. If I make the same move twice I don't disorient anything.

Agreed.

Okay cool

For the moves that disorient, two of the cubes are disoriented by 1, and two by 2.

So 1 + 1 + 2 + 2 = 6, the change in orientation.

Does that make sense?

Starting from the solved state?

From any state. Let's say that corners are oriented (0), rotated once (1), or rotated twice (2). From the solved state, moving the front face, for example, changes the orientations of the 4 corners cubies on that face from 0, 0, 0, 0, to 1, 1, 2, 2.

So the total change in orientation is always 6 for 90-degree twists of faces that disorient corners.

I don't think I follow what counts as disoriented

If white is up top and red is front: any corner that has red pointed up or down is oriented.

Any corner that has white or yellow pointed up or down is disoriented by 1.

Any corner that has blue or green pointed up or down is disoriented by 2.

(And that definition is arbitrary.)

That's from Ryan Heise: ryanheise.com/cube/cube_laws.html

I have various implementations of the RC, but I think this definition is most concise: github.com/benbotto/rubiks-cube-cracker/blob/master/Model/…

Ohhhh. I see.

I think the way I originally saw it still works

Using only four sides for moves

You mean that 4 of the sides change the orientations of corners with 90-degree twists, and 2 of the sides don't change the orientations?

The top and bottom don't change orientations right?

So I can just focus on the 4 sides. Left right front and back

I'm checking something now

All right. Thanks again for the help.

I'm over here hacking away on my calculator. It's just too convenient that 3^8-48 = 6513.

Doing any single move twice in a row doesn't affect orientation. Doing a single move once does. When I look at the kind of permutation that's done when a move is performed, all the moves are "Odd" permutations.

Yes, I agree.

The number of odd permutations in a permutation group is half the full size of the group

Yep yep.

I thought the group has a size of 40,320

Also, because the total change in orientation is always 6 for disorienting twists, which is divisible by 3, the corner orientation is always divisible by 3.

so there'd be 20,160 odd states

Right

I'm going to sleep on it.

Good night

Okay. Thanks again! Let me know if you figure it out, and I'll do the same.

Night.

Sounds good. Peace