Thread: "{4,4,4}"

At first I thought about {3,infinity} as a puzzle with material overlappi=
ng twists. So each cell has 7 stickers (one 1C, three 2C and three infinite=
-C). Once you get periodic coloring of the puzzle (and there is a lot of th=
em), vertex pieces will look as a periodic sequence of colors. For example,=
for 8-color scheme you'll get 6 vertex pieces with colors (0132), (0264), =
(0451), (4675), (1573) and (2376). Actually, it will be {3,4} spherical puz=
zle. Also {3,infinity} will include {3,6}, {3,7} and all other similar obje=
cts :) BTW, {infinity,3} gives easy way to find coloring schemes for {N,3}.=
For example, there is 36-colors for {9,3}, but I'm not sure about 12- or 1=
8-colors.
Alterantive way is to use deep-cut of {3,infinity} with movable centers o=
f adjacent faces but unmovable (and non-rotating) vertex pieces. Or enable =
rotation of oricycles containing vertecies as well, but it will be differen=
t puzzle... What is {3,infinity} rectified? Something strange (like (3,infi=
nity,3,infinity) polyhedron).
For {4,4,4} (that can be built from the checkerboard coloring of {4,4,3} =
by expanding of only black cells) I also think about twists with material o=
verlapping. Vertex pieces there will have periodic 2D ({4,4}) coloring, and=
it will be difficult to describe their "position and orientation".
Slicing of {4,4,4} without overlapping should be very difficult. But fixe=
d positions and orientations of vertecies may help a lot - if "centers" of =
cells will be movable (it's a joke, of course: these centers are ideal poin=
ts as well).

Too many things to do and absolutely no time for them... I want hyperboli=
c metrics of the time!

Good luck!
Andrey



--- In 4D_Cubing@yahoogroups.com, Roice Nelson wrote:
>
> I was also thinking some yesterday about this thread between Andrey and
> Nan. Puzzles with infinite-sided cells seemed understandable (now that
> Andrey has shown the way!), but I had been having trouble wrapping my hea=
d
> around puzzles with infinite-sided vertex figures. So although I could s=
ee
> the {infinity,3} puzzle Andrey suggested would be a nice addition to
> MagicTile (even if the programming might be difficult), thinking about
> {3,infinity} was confounding. How would *that* behave?
>=20
> I went back to Don's pictures that Melinda emailed about, and looked at t=
he
> two views he has of the {3,infinity} tiling (the dual to the {infinity,3}=
).
> What is interesting is that the cells are "ideal triangles" - all the
> cell vertices lie at infinity, on the boundary of the disk. They are
> infinite in extent *in multiple directions* (though not infinite in area)=
.
> So then I thought about how one would twist one of these cells, and
> concluded that it would not be possible to (isometrically) twist a cell
> without it overlapping other parts of the puzzle, since the vertices will
> remain on the disk boundary through the motion. So if you want to have a
> puzzle with an infinite vertex figure, you'll be forced to have it behave=
in
> an impossiball-like fashion (at least for 2D puzzles).
>=20
> Furthermore, the slicing becomes degenerate for a {3,infinity} puzzle unl=
ess
> you want make some modifications to the previous MagicTile generalization=
.
> If you stick to circle slices (or sphere slices in H3), the only slicing
> circle encompassing the entire cell is the disk boundary itself, and a tw=
ist
> using that would be a rotation of the entire space. It would not permute
> anything. One option would be to have slicing circles which did not cont=
ain
> the entire cell though, and this could lead to some interesting puzzles.
> That seems like the only good way forward to me actually.
>=20
> I think the {4,4,4} situation will have some similarities to these
> thoughts. Each cell in the {6,3,3} tiling only has one ideal point at
> infinity, but the cells in the {4,4,4} tiling will have an infinite numbe=
r
> of ideal points. It seems the result is that any twist (which moves all =
the
> material in a cell) will lead to overlapping material in the puzzle (?, I=
'm
> not 100%). The slicing certainly suffers from the same issues described
> above. It is the normal problems of puzzles without simplex vertex figur=
es
> multiplied by a gazillion!
>=20
> Well, I could probably spew more, but I'll stop in the hope that this
> doesn't all just sound like gibberish. I realize that if one
> didn't have some familiarity with the disk/ball models of hyperbolic spac=
es,
> it probably would. (The first six chapters of Visual Complex
> Analysisit-20&linkCode=3Das2&camp=3D1789&creative=3D390957&creativeASIN=3D019853446=
9>
> are
> awesome for learning about these models btw.)
>=20
> Roice
>=20

--001636c5c2f44c1e170494279fcc
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 3, 2010 at 2:23 AM, Andrey wrote:

> What is {3,infinity} rectified? Something strange (like
> (3,infinity,3,infinity) polyhedron).


You can see the rectified {3,infinity} on Don's tessellation
page.
The rectified tilings are the ones with a tessellation value of 2. Two
views of the rectified {3,infinity} tiling are
hereand
here
(the
blue lines those pictures), and you were right. The tiling is made of
4-gons with two ideal vertices, and three tiles meeting at both of the other
two vertices.

Roice

--001636c5c2f44c1e170494279fcc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

--00151747bcb4ea0a31049427d1bf
Content-Type: text/plain; charset=ISO-8859-1

Please excuse the typo. The rectified tilings are the ones with a
*truncation* value of 2.

Roice

On Wed, Nov 3, 2010 at 10:23 AM, Roice Nelson wrote:

>
> On Wed, Nov 3, 2010 at 2:23 AM, Andrey wrote:
>
>> What is {3,infinity} rectified? Something strange (like
>> (3,infinity,3,infinity) polyhedron).
>
>
> You can see the rectified {3,infinity} on Don's tessellation page.
> The rectified tilings are the ones with a tessellation value of 2. Two
> views of the rectified {3,infinity} tiling are hereand
> here (the
> blue lines those pictures), and you were right. The tiling is made of
> 4-gons with two ideal vertices, and three tiles meeting at both of the other
> two vertices.
>
> Roice
>

--00151747bcb4ea0a31049427d1bf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable