Rubik's Cube in Prolog – Order

I'm not sure if anyone has noticed, a rubiks cube can be represented by only the orientations of the pieces. You do this by defining their "correct" position in cube coordinates rather than piece coordinates (local about the piece center). In other words you might define a 3d model for each piece in world space assuming the cube as a whole is centered on the origin. With pieces offset from the origin like this, any rotation about an axis will appear to move the piece as well as rotate it. With 24 orientations, you'll find 3 that place a corner in the same position but colors rotated. Similarly edges have 2 orientations for each of 12 locations.

One does need to compute the traditional position of the pieces to determine which ones need to be rotated for a given move, but the total state is significantly reduced.

Tell me this isn't news to the cube world. It cant be. Can it?

Prolog's pattern matching makes this elegant. The constraint-based approach for state space pruning is clever.

Fun article! Makes me want to play with prolog again.

I put together something looking at a rubik's cube as a permutation of numbers a while back. https://taeric.github.io/cube-permutations-1.html I remember realizing that my representation essentially had some permutations of numbers that it would never hit, but wasn't sure it was worth trying to more directly model the pieces of the cube. Curious if there are advantages here that I'm ignoring.