Message #1555

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 22:23:26 -0500

more inlines :)

On Sun, Mar 13, 2011 at 3:58 PM, schuma wrote:

> 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.
>

Yeah, it’s a bit of a bummer. Luckily in this case we can get it to work
without waiting for the next gen program. I just calculated the factor
needed for the hexagonal puzzles, and it is 3*sqrt(3)/4, an irrational
number. If you go out enough digits though, it will work. I entered
1.29903810567 and checked a saved log file to make sure the right number of
stickers were there. I’ll explain why this approximation works below. Of
course, I don’t want to burden the user with this kind of grossness, so I
hope with a better design, it can be simpler, where the configuration will
just be 2 * radius of incircle (or 1.5 * diameter).

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.
>

This is true, but it is something that these puzzle programs have to deal
with in various places already. For example, after a twist, I compare new
sticker locations to old ones to update the state, but the calculation of
the twist can make the new locations ever so slightly off. So there is a
vector class in my code which does fuzzy comparisons of locations (on the
order of errors you get with floating point arithmetic calculations plus a
nice big safety buffer). As long as the slicing code is made aware of this,
things should be ok.

However, there will always be a cutoff where slivers will pop into
existence. So with this example, if someone does a slicing factor of 2.001
* incircle radius, there would still be tiny slivers, which probably
wouldn’t be visible.

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.
>

ah, ok.

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.
>

This is interesting, and gets into Melinda’s previous
email<http://games.groups.yahoo.com/group/4D_Cubing/message/1464>about
the aesthetics of puzzles. I think for version 2 (I hate version
numbers, but think I should just give in and label the next iteration I’ve
been working on), I think I’ll choose to not include a puzzle like the {8,3}
with factor 1.29 in the default menu, because of my heavy bias towards
having a valid geometrical/topological interpretation. But I certainly want
the code to support as much as possible, such that users could still have
the opportunity to get at puzzles like it.

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

Absolutely :) It’s been there from the initial release, and I’ve been
looking forward to the time when the topic would get discussed ever since.
So thank you for exploring things and providing such valuable feedback!
The timing is good, as I’m in the process of a full rework of the code for
v2.

I look at solvers of deep-cut puzzles as a random person might look at
someone who can solve the Rubik’s Cube… with awe!

All the best,
Roice