Message #3337

From: Roice Nelson <roice3@gmail.com>
Subject: Re: [MC4D] Re: Research Project [4 Attachments]
Date: Wed, 20 Apr 2016 10:34:53 -0500

Hello and welcome!

I like your recursive representation. I *think* it is the same that Don
Hatch used in his n-dimensional cube solver.
http://www.plunk.org/~hatch/MagicCubeNdSolve/

Check out the docs of that here. His 3^4 looks the same as yours, and he
also has a 3^5 example.
http://www.plunk.org/~hatch/MagicCubeNdSolve/javadoc/

On the question of moves… Yes, limiting to the "simple" 90 degree twists
is enough to reach any position of the puzzles. The extra freedom allowed
in higher dimensions by twists that are not aligned with the coordinate
axes are interesting, but they don’t increase the state space of the
puzzles.

Cheers,
Roice


On Wed, Apr 20, 2016 at 8:07 AM, m_a_kl@yahoo.com [4D_Cubing] <
4D_Cubing@yahoogroups.com> wrote:

> [Attachment(s) <#m_5784050346085645578_TopText> from m_a_kl@yahoo.com
> [4D_Cubing] included below]
>
> Hello all,
>
> I’m also new to this group. The MC7D program is not the only appropriate
> way to visualise a 3^7-Rubik’s cube, so you might understand this one
> (which I hope is equivalent) better. I attached a bitmap picture showing a
> different method not doubling labels; each non-white pixel stands for one
> label and vice versa. It is constructed iteratively: To increase dimension
> by one, the pattern is repeated three times and then "front" (with respect
> to the new dimension) and "back" labels are added. Start pattern is
> raster-2.png, in which each of the little squares is a label. If you
> combine two of these steps by arranging 3x3 patterns and then adding
> "left", "right" resp. "top", "bottom" labels, you don’t fill a line but a
> plain, thus obtaining a more compact representation (see raster-4.png for
> the image of a 3x3x3x3-Cube after one double step).
>
> By the way, the pictures were generated by a program, which I extended to
> execute moves on the cube, so I use this opportunity to put a question to
> this group, too. My program only allows "simple" moves: At first, one third
> of the cubies is selected by fixing one coordinate to be 1 or (-1); then
> two different coordinates x_i and x_j are chosen and every selected cubie
> is rotated in the (x_i, x_j) plane, only changing its x_i and x_j
> coordinate. I hope that this is enough to execute all possible moves by
> combining simple moves, for any dimension? Please inform me if I’m
> incorrect or if I have to be more specific.
>
> By the way: The above iteration puts pixels into the plain such that any
> bounded region receives pixels until a certain dimension is reached, and
> then it is fixed. By noticing that the way of entering moves described in
> the previous paragraph does not depend on the total number of dimensions
> handled by the program, it can be regarded as "arbitrarily-dimensional
> Rubik’s cube simulator".
>
> Kind regards!
>
>
>