Message #136

From: Roice Nelson <roice@gravitation3d.com>
Subject: Re: [MC4D] "Physical models" of Rubik’s Cube (tesseract, hypercube, etc.)
Date: Tue, 19 Apr 2005 19:33:14 -0500

> The question that I have then becomes "What is the set of inertial
> rotations I get when I decompose each of the 192 rotations of the
> hypercube?", and more importantly "Are these inertial rotations a
> subset of the original 192?" Allowing a rotation which doesn’t put
> the hypercube back in it’s place would be bad. If the answer to the
> second question is ‘yes’, then since any sequence of orthogonal
> inertial rotations would be "conceptually independent" to the user
> there is no need to have moves which perform two or more of them
> simultaneously.

> I would argue there is no need to have a move which performs these
> rotations simultaneously.


I can buy your conclusion, but my reasoning comes from a different
perspective.

At first I disagreed. I thought it would be better to explicitly
define all 192 rotations. The reason is similar to the reason for
MagicCube4D providing limited click rotations to any of the 24
possible 3D face orientations (3 of the orientations do require 2
clicks, and the null orientation of course 0). So why not have
MagicCube5D provide a minimal click method to rotate its 4D faces to
any of the possible 192 orientations? MagicCube4D does it for its
non-commutable sequences after all (and we all agree this is part of
the elegance), and whether sequences of rotations are commutable or
not doesn’t seem important to me in regards to this.

With this line of thought, it seemed better to include all 192
rotations as single (or minimal) click entities for convenience and
elegance, the different end results being the "conceptually
independent" items. But after thinking shortly about the interface of
MagicCube5D, I have changed my internal tune a bit and now agree with
you more. Because of the "orthogonal inertial rotations", it would
not be possible to generate all of the 192 face orientations by
rotating through a single axis as in MagicCube4D. So the extra
information required means we can’t just make a single sticker click
rotate to any of the orientations we want. Maybe there would be some
elegant way to do so based on where you clicked on the 4D hypercubie
stickers (that is if MagicCube5D could even be presented in any sort
of elegant way). The reason I agree with your conclusion more now is
my intuition tells me creating an interface that works only with the
component inertial rotations would be significantly simpler.

I hope I have explained my intuition and reasoning decently here and
am not off track. Anyway, since this portion of the discussion could
be considered mostly related to MagicCube5D, how should we setup the
interface for it? :) First 3x3x3x3x3 solution is still up for grabs!

Roice