Message #1554

From: schuma <mananself@gmail.com>
Subject: Re: Magic Tile {8,3} 6 Colors, 3 Layers, Slicing factor = 1.15 solved
Date: Sun, 13 Mar 2011 20:58:23 -0000

Hi Roice,

It’s sad to hear that 1.3 is not the sweet spot. I actually solved {6,3} with factor =1.3 only for 3 colors and 4 colors. Luckily the tiny pieces didn’t cause any trouble. I should have magnified it.

If you define the factor with respect to incircle/circumcircle, I wonder if the limited precision of irrational numbers will come in and create tiny pieces (of size 10^{-16} for example). What I meant is, even if the factor is something nice like 1.5 or 2, some internal variables in the program can be irrational and cause the problem.

For {8,3} factor =1.29, I didn’t intend to make the circles tangential. But the small pieces don’t matter because at the centers of the flowers all the pieces are always the same color. I chose 1.29 simply because 1.28 doesn’t work and 1.30 makes the corners too small.

About the "glitchy animation", this is my logic: If you set the rotation rate to 1 (instantaneous twisting), all the pieces follow a well-defined permutation. Only when the rotation rate < 1, you need to worry about whether a piece is going to the left or to the right. But moving to the left or right doesn’t matter, as long as the destination is the same. Therefore I take it as a well defined puzzle rather than an ill defined one.

Finally, thank you for adding this setting. I enjoy exploring these puzzles.

Nan

— In 4D_Cubing@yahoogroups.com, Roice Nelson <roice3@…> wrote:
>
> 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
>