Message #1551

From: Roice Nelson <roice3@gmail.com>
Subject: Re: [MC4D] Re: Magic Tile {8,3} 6 Colors, 3 Layers, Slicing factor = 1.15 solved
Date: Sun, 13 Mar 2011 12:37:01 -0500

some inlines below (mainly related to things to watch out for until I get
the code better designed and working).

On Sun, Mar 13, 2011 at 4:22 AM, schuma wrote:

> + {6,3} 16 and 25 colors: factor = 1.3. Neat pattern. The edges are like
> the edges in pyraminx or pyraminx crystal, which can be 3-cycled using a
> four-move commutator. Therefore solving is nontrivial but not hard.
>

I think the intent here is for circles to go through the centers of adjacent
cells but unfortunately, there are tiny pieces created with the 1.3 factor.
And my guess is a solution would not automatically solve the tiny pieces.
The problem is that 1.3 is not the true "sweet spot". More on this below.

> + {6,3} 9 colors: factor = 1.3. The edge pieces cannot be easily solved
> like in 16 and 25 colors. I don’t understand the behavior of them. This
> seems to be an interesting puzzle.
>

Same "tiny slivers" issue here.

• {8,3} 6 colors: factor = 1.15. It’s the puzzle I talked about earlier.
  > Regular Rubik’s cube plus a special type of edges. A compact and challenging
  > puzzle.
  >

Just wanted to say thank you for analyzing and solving this one. I enjoyed
reading your previous email on it, and hearing that the edge piece were
special and new. That’s really cool to hear.

• {8,3} 6 colors: factor = 1.29. This is really a weird looking puzzle.
  > Neglecting glitchy animation, I find it an interesting one. When it’s
  > scrambled, it looks weird, weird, weird. At the center of each circle there
  > is a daisy with eight petals. In principle it is equivalent to Rubik’s cube
  > but you always turn two faces (e.g. R and MR, it is equivalent to turning L’
  > and reorient the cube). The checkerboard pattern on the Rubik’s cube looks
  > more like a "daisy" pattern in this puzzle.
  >

A couple things to comment on here:

About the "glitchy animation" (which you also mentioned earlier), this
happens when slicing circles become so big that they intersect their copies.
At that point, I think the puzzle is ill defined from a mathematical
perspective (it seems a piece should either live in the fundamental domain
or an image of it, not both at once). Given this, your observations about
the puzzles whose states still work out are interesting.

The second comment then is that I figure you intended the puzzle where the
slicing circles and their copies are tangent (factor slightly less than
1.29). With the 1.29 factor, we yet again have the slivers problem (zooming
in on this one shows a scary number of tiny pieces).

> + Hemi-Dodecahedron 6 colors. Another rich family of puzzles, whereas this
> family is unique in Magic Tile. I interpret them as slice-only face-turning
> dodecahedra. For example, if factor = 1.75, it’s a slice-only Starminx.
> Unfortunately I cannot find the sweet spot to make a slice-only pyraminx
> crystal. The tiny pieces are always around.
>

On pyraminx crystal, factor = 1.288 gets you really close, but there are
still slivers. 1.2885 is even closer, and starts to expose some other
problems caused some of the slicing circles getting projected to lines
(which needs better handling). Those linear slices are one thing I find
quite neat about the pyraminx crystal in MagicTile though, so I will be
making an effort to get it working.

Anyway, I have started thinking some about how to have better general
support for configuring slicing circles, but haven’t come up with the
"right" solution yet. Here’s a couple things I have the feeling will be
important to support all the cases:

(1) The expansion factor will need to be something that is applied in the
respective geometries, whereas right now it is a euclidean expansion.
(2) In order to support cases like the pyraminx crystal and what you are
going for on the hexagonal puzzles with a 1.3 factor, I’m going to need to
allow the expansion be defined relative to an
incircle<http://en.wikipedia.org/wiki/Incircle>,
rather than have the expansion defined relative to the 3-length slices. So
configuring a circle to go through the center of an adjacent cell will be a
1.5 factor of the incircle. Expansions relative to the
circumcircle<http://en.wikipedia.org/wiki/Circumcircle> will
also need to be supported (perhaps all existing puzzles in the menu can be
defined relative to the these). Hopefully I’m making sense, but the main
issue that needs to be overcome is that we need to make sure the important
depths can be specified as simple fractions of some standard circles. If
the factors need to be irrational numbers or fractions with many decimal
points, users won’t be able to configure what they want without slivers
arising (or worse, they’ll think they have a good puzzle when they don’t).
If anyone has good design thoughts on this, I’ll appreciate them.
Otherwise, I’m sure I’ll figure it out better when I get into this part of
the programming.

Despite the current weaknesses, I’m glad I added this experimental setting
because it is leading to this discussion, and should help us hone in on the
best approach to support deep-cut puzzles.

Finally, "slicing circle expansion factor" sure feels like clumsy naming.
Any other terminology we could steal from the deep-cut puzzle world that
might be better?

Take Care,
Roice