# Message #1440

From: Roice Nelson <roice3@gmail.com>

Subject: Re: [MC4D] Social dream

Date: Tue, 22 Feb 2011 09:26:53 -0600

I very much like what Andrey specified for the twist definition in future

log files.

The only thing I questioned while reading was whether it is necessary to

store the rotation angles in such a way that they depend on the puzzle. So

rather than storing 12/3=4 for a 120 degree rotation on the simplex, why not

simply store 3? This would make those values more readable across puzzles,

since any order-3 rotation would be saved the same. Maybe I am missing

another need there though.

Roice

On Mon, Feb 21, 2011 at 1:11 AM, Andrey <andreyastrelin@yahoo.com> wrote:

> Hi all,

> About piece finding and percentage of solving, there is a problem in the

> most puzzles: if puzzle has no unmoving center of the cell, you cannot say

> what is the proper color for this cell. So there is no way to say "what is

> the place for this piece", "where this piece should go" and "how many

> pieces/stickers are in their places". Program can "guess" colors for faces

> (by majority of colors), but is may lead to strange situatons: you solve

> something like simplex, get one twisted corner piece, and can’t solve it

> without reassigning colors to cells. But the program keeps telling you that

> you are going from the correct solution, and number of solved pieces is

> decreasing (until you get enough stickers in their new cells)

> So I used alternative approach to piece-finding in MC7D. It works, but

> it’s much less intuitive than "click in piece and see where it goes".

>

> As for the log files, my first idea is the following.

> Let we have some puzzle based on uniform polytope. Now we don’t consider

> shape-transformers, so form of puzzle remains the same after each twist.

> Cutting hyperplanes are ortogonal to some axes (going through the center

> of the puzzle). These axes may contain centers of cells, 2D faces, middles

> of edges and vertices of the puzzle, but it doesn’t matter. What is

> important, the set of axes for the puzzle is a subset of symmetry/rotation

> axes of the puzzle body. There are not many symmetry sets in 4D:

> - symmetries of 5-cell (15 axes)

> - symmetries of bitruncated 5-cell (70 axes?)

> - symmetries of 8-cell (40 axes)

> - symmetries of 24-cell (120 axes)

> - symmetries of bitruncated 24-cell (624 axes?)

> - symmetries of 120-cell (1320 axes)

> - symmetries of duoprism [n]x[k] (n+k axes?)

> - symmetries of duoprism [n]x[n] (2*n+n^2 axes?)

>

> We can enumerate axes for every case in some agreed order.

>

> For every axis we have number and positions of cutting planes. They define

> number and connections of stickers, but almost don’t influence rotation

> descriptions. We need to define mask of layers for the twist, and for that

> we must know only one thing - what is the maximal number M of layers there

> is from the center to the surface (for all axes) - not including central

> layer. For example, for 3^4 tesseract it will be 1, and for 3^4 with

> diagonal cuttings x±y±z±w={-2,0,2} (for x,y,z,w={-1,1}) it will be 2 (there

> are 3 layers orthogonal to (0,0,0,1) and 4 layers orthogonal to (1,1,1,1) ).

> If such number M is defined, we enumerate layers by each axis so that

> central layer (if it exists) has number M. If thare is no central layer, M

> is skipped. For the example above layers parallel to cells will have numbers

> 1,2,3 and layers in 0D direction (orthogonal to (1,1,1,1)) will be 0,1,3,4.

> This way we define the mask of the twist.

>

> To define the twist we need two more things - direction of 3D axis of twist

> and twisting angle. My guess is that 3D axis is always one of symmetry axes

> that is perpendicular to the layer axis, so it is enumerated in our set. The

> problem will be with the angle.

>

> Some puzzles (such as 3x3x4x4, or alternated puzzles like snub 24-cell) may

> have restricted set of twists enabled by the axes set. So we can’t just

> write "turn on smallest possible angle clockwise", we need to define angle

> explicitly. I suggest to select some number D for every axes set, that will

> be common divisor for all twist orders (not necessarily the least) - 12 for

> simplex, hypercube or 24-cell, 60 for 120-cell, [n,k,2] for duoprism,

> include it in the set description and write angles assuming D=360 deg.

> So every twist will be described by 4 numbers:

> - direction of main axis (orthogonal to the cutting plane)

> - direction of 3D axis (it’s perpendicular to the main axis)

> - rotation angle

> - layers mask

>

> For example, 120-deg rotation of 3rd layer of 4^4 may have the form

> A1:A2:4:8, where A1=(1,0,0,0) and A2=(0,1,-1,1) (4=12/3, 8=2^3)

>

> I don’t want to include complete stickers mask in the description (stickers

> order and description may be different for different implementations), and

> don’t see good way to define the starting situation. Of course, we can find

> the description for every sticker It may include 4 cutting planes that give

> its vertex, and a mask that gives position of the sticker relative to these

> planes. But definition of the puzzle state is such terms will be terrible. I

> afraid that we will be able to keep only possible positions defined by the

> twists sequence.

>

> All the other things - body shape, coloring, position of cutting planes,

> mask/description of stickers, not included in puzzle (and the shape of the

> remaining stickers), bandaging and so on - it will be in the log header and

> its interpretation (= puzzle description) is another story.

>

> Andrey