I'm trying to throw together some quick and dirty javascript code to give me the number of possible piece permutations on a rubik's cube given a constraint such as "1 edgepiece is solved". (sticking to 3x3 for simplicity) When I run the normal 12 edgepieces and 8 corners through my function, it's giving me a number that is 4000 greater than what I'm able to find should be the answer. (Function gives me 43,252,003,274,489,860,000 but https://www.youtube.com/watch?v=z2-d0x_qxSM says it should be 43,252,003,274,489,856,000)
My code:
// 3x3x3 Rubik's Cube
edgepieces = 12;
cornerpieces = 8;
centerpieces = 6;
// total possible permutations in general
function numCombos(edges, corners) {
result = ((factorial(edges) * (factorial(corners)) / 2) * (2 ** (edges - 1)) * (3 ** (corners - 1)));
return result;
}
// n!
function factorial(x) {
if (x == 0) {
return 1;
} else {
return x * factorial(x - 1);
}
}
console.log(numCombos(edgepieces, cornerpieces) + '\n');
I have followed a couple different arrangements for the core result algorithm, and they all give me this end result. What am I missing?
You can use BigInt values to avoid floating-point precision issues:
// 3x3x3 Rubik's Cube
edgepieces = 12n;
cornerpieces = 8n;
centerpieces = 6n;
// total possible permutations in general
function numCombos(edges, corners) {
result = ((factorial(edges) * (factorial(corners)) / 2n) * (2n ** (edges - 1n)) * (3n ** (corners - 1n)));
return result;
}
// n!
function factorial(x) {
if (x == 0) {
return 1n;
} else {
return x * factorial(x - 1n);
}
}
console.log(numCombos(edgepieces, cornerpieces) + '\n');Double-precision floating-point numbers have 53 bits of precision, which is almost 16 digits of precision.[1] You expect a result with 17 digits of precision. It's possible the number can't even be represented by a double.
The simple solution is to use BigInt numbers instead of floating point numbers.