# 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

>