Message #1460

From: Andrey <andreyastrelin@yahoo.com>
Subject: Re: [MC4D] Social dream
Date: Mon, 28 Feb 2011 10:32:28 -0000

Hi Andy,
I see 12 more rotational planes: they have fixed bivectors (1,1,0,0)x(0,0,1,1) with sign changes and coordinate permutations.
These planes can’t be used in 3D-centered twists (because bi-axis doesn’t contain coordinate vectors), but there is a couple of 180-deg twists with them:
2D-centered twist is here: <img src="http://groups.yahoo.com/group/4D_Cubing/photos/album/1184359940/pic/527704145/view" />
and 0D-centered is here: <img src="http://groups.yahoo.com/group/4D_Cubing/photos/album/1184359940/pic/579107863/view" />

So if you have some rotation in 4D around the plane [P,Q] where P and Q are some vectors, you may select any cutting plane perpendicular to vector R from [P,Q] and then rotate the slice around some other vector R1 from [P,Q].

For example, in the most simple situation when bi-axis is (1,0,0,0)x(0,1,0,0), one can use it to rotate any of 4 dufferent 3D cells (R=(1,0,0,0) or (0,1,0,0)), or any of 4 2D ridges (R=(1,1,0,0) or R=(1,-1,0,0)).

When I wrote my description of twist, I thought that if we select vector R1 perpendicular to R, then it will be an axis of the figure. But now I see that it’s wrong: if we take R=(1,1,1,1) (0D-centered twist) and perform 120-degree rotation, then actual axis R1 will be something like (-3,1,1,1) that is not any axis of the tesseract. Of course, I can write in log that R1=(0,1,1,1) or (1,0,0,0) (so that [R,R1] gives the rotation bi-axis), but such selection will be arbitrary, not canonical, and I’m not sure that the rotational bi-axis will always contain two axes of the figure.

It looks like we should enumerate all rotational planes as well as axes, and use orthogonal pairs (axis,plane) in the log file.

This method will work for all finite puzzles where twists can be defined in 2D way (with D-2 dimensional multy-axis), but there will be a lot of external data for the axes set definitions (list of axes, and list of planes - and there are some infinite families of sets…) So format will be not as elegant as it supposed to be.

For 3^5 there is a restricted set with only 5 axes and 10 rotational planes - and only 30 axis/plane pairs may appear in log. For 3^7 there are 7 axes and 21 planes (105 possible combinations) an for 5D simplex we have 6 axes and 20 planes (or 10? not sure) that give us 120 deg-twists of faces.

Andrey

— In 4D_Cubing@yahoogroups.com, "Andrew Gould" <agould@…> wrote:
>
> I’m seeing 46 rotational planes for the tesseract (6 planes for 90-degree
> rotations, 24 for 180-degree, 16 for 120-degree), now I’m trying to
> translate into Andrey’s 40 axes–I got confused.
>
>
>
> I’m keeping my so-called "2D twists" in mind. They seem to use the same
> axes/rotational planes that are already used.
>
> http://groups.yahoo.com/group/4D_Cubing/photos/album/1774759718/pic/list
>
>
>
> The deal in 5D is that you can twist 4D slices, 3D slices, or 2D
> slices…but again I’m seeing that they all get twisted about
> axes/rotational planes that are already used for twisting 4D slices.
>
>
>
> –
>
> Andy
>
>
>
>
>
> From: 4D_Cubing@yahoogroups.com [mailto:4D_Cubing@yahoogroups.com] On Behalf
> Of Andrey
> Sent: Monday, February 21, 2011 1:12
> To: 4D_Cubing@yahoogroups.com
> Subject: Re: [MC4D] Social dream
>
>
>
>
>
> 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
>