--0015175cf764909160049e60a47c
Content-Type: text/plain; charset=ISO-8859-1
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
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
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
--0015175cf764909160049e60a47c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
get the code better designed and working).gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;">
=A0+ {6,3} 16 and 25 colors: factor =3D 1.3. Neat pattern. The edges are li=
ke the edges in pyraminx or pyraminx crystal, which can be 3-cycled using a=
four-move commutator. Therefore solving is nontrivial but not hard.
lockquote>
e centers of adjacent cells but unfortunately, there are tiny pieces create=
d with the 1.3 factor. =A0And my guess is a solution would not automaticall=
y solve the tiny pieces. =A0The problem is that 1.3 is not the true "s=
weet spot". =A0More on this below.=A0border-left:1px #ccc solid;padding-left:1ex;">=A0+ {6,3} 9 colors: factor =
=3D 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 interestin=
g puzzle..8ex;border-left:1px #ccc solid;padding-left:1ex;">=A0+ {8,3} 6 colors: fac=
tor =3D 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.
and solving this one. =A0I enjoyed reading your previous email on it, and h=
earing that the edge piece were special and new. =A0That's really cool =
to hear.;border-left:1px #ccc solid;padding-left:1ex;">
=A0- {8,3} 6 colors: factor =3D 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 ther=
e 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 tu=
rning L' and reorient the cube). The checkerboard pattern on the Rubik&=
#39;s cube looks more like a "daisy" pattern in this puzzle.
lso mentioned earlier), this happens when slicing circles become so big tha=
t they intersect their copies. =A0At that point, I think the puzzle is ill =
defined from a mathematical perspective (it seems a piece should either liv=
e in the fundamental domain or an image of it, not both at once). =A0Given =
this, your observations about the puzzles whose states still work out are i=
nteresting.
he puzzle where the slicing circles and their copies are tangent (factor sl=
ightly less than 1.29). =A0With the 1.29 factor, we yet again have the sliv=
ers problem (zooming in on this one shows a scary number of tiny pieces).div>border-left:1px #ccc solid;padding-left:1ex;">=A0+ Hemi-Dodecahedron 6 colo=
rs. 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 =3D 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.
you really close, but there are still slivers. =A01.2885 is even closer, an=
d starts to expose some other problems caused some of the slicing circles g=
etting projected to lines (which needs better handling). =A0Those linear sl=
ices are one thing I find quite neat about the pyraminx crystal in MagicTil=
e though, so I will be making an effort to get it working.
better general support for configuring slicing circles, but haven't com=
e up with the "right" solution yet. =A0Here's a couple things=
I have the feeling will be important to support all the cases:
is applied in the respective geometries, whereas right now it is a euclide=
an expansion.
stal 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 href=3D"http://en.wikipedia.org/wiki/Incircle">incircle, rather than ha=
ve the expansion defined relative to the 3-length slices. =A0So configuring=
a circle to go through the center of an adjacent cell will be a 1.5 factor=
of the incircle. =A0Expansions relative to the=A0pedia.org/wiki/Circumcircle">circumcircle=A0will also need to be suppor=
ted (perhaps all existing puzzles in the menu can be defined relative to th=
e these). =A0Hopefully 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 spe=
cified as simple fractions of some standard circles. =A0If the factors need=
to be irrational numbers or fractions with many decimal points, users won&=
#39;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). =A0If any=
one has good design thoughts on this, I'll appreciate them. =A0Otherwis=
e, I'm sure I'll figure it out better when I get into this part of =
the programming.
is experimental setting because it is leading to this discussion, and shoul=
d help us hone in on the best approach to support deep-cut puzzles.
re feels like clumsy naming. =A0Any other terminology we could steal from t=
he deep-cut puzzle world that might be better?
e Care,
--0015175cf764909160049e60a47c--
From: Roice Nelson <roice3@gmail.com>
Date: Sun, 13 Mar 2011 22:23:26 -0500
Subject: Re: [MC4D] Re: Magic Tile {8,3} 6 Colors, 3 Layers, Slicing factor =
--000325559986c2b81b049e68d52b
Content-Type: text/plain; charset=ISO-8859-1
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
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
--000325559986c2b81b049e68d52b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
11 at 3:58 PM, schuma=A0wrote:=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It'=
s sad to hear that 1.3 is not the sweet spot. I actually solved {6,3} with =
factor =3D1.3 only for 3 colors and 4 colors. Luckily the tiny pieces didn&=
#39;t cause any trouble. I should have magnified it.
y in this case we can get it to work without waiting for the next gen progr=
am. =A0I just calculated the factor needed for the hexagonal puzzles, and i=
t is 3*sqrt(3)/4, an irrational number. =A0If you go out enough digits thou=
gh, it will work. =A0I entered 1.29903810567 and checked a saved log file t=
o make sure the right number of stickers were there. =A0I'll explain wh=
y this approximation works below. =A0Of course, I don't want to burden =
the user with this kind of grossness, so I hope with a better design, it ca=
n be simpler, where the configuration will just be 2 * radius of incircle (=
or 1.5 * diameter).;border-left:1px #ccc solid;padding-left:1ex;">
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 p=
ieces (of size 10^{-16} for example). What I meant is, even if the factor i=
s something nice like 1.5 or 2, some internal variables in the program can =
be irrational and cause the problem.
e puzzle programs have to deal with in various places already. =A0For examp=
le, after a twist, I compare new sticker locations to old ones to update th=
e state, but the calculation of the twist can make the new locations ever s=
o slightly off. =A0So there is a vector class in my code which does fuzzy c=
omparisons of locations (on the order of errors you get with floating point=
arithmetic calculations plus a nice big safety buffer). =A0As long as the =
slicing code is made aware of this, things should be ok. =A0
ll pop into existence. =A0So with this example, if someone does a slicing f=
actor of 2.001 * incircle radius, there would still be tiny slivers, which =
probably wouldn't be visible.;border-left:1px #ccc solid;padding-left:1ex;">
For {8,3} factor =3D1.29, I didn't intend to make the circles tangentia=
l. But the small pieces don't matter because at the centers of the flow=
ers 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.ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex;">
About the "glitchy animation", this is my logic: If you set the r=
otation rate to 1 (instantaneous twisting), all the pieces follow a well-de=
fined permutation. Only when the rotation rate < 1, you need to worry ab=
out 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=
.
's 4">previous email about the aesthetics of puzzles. =A0I think for versi=
on 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 i=
nclude a puzzle like the {8,3} with factor 1.29 in the default menu, becaus=
e of my heavy bias towards having a valid geometrical/topological interpret=
ation. =A0But I certainly want the code to support as much as possible, suc=
h that users could still have the opportunity to get at puzzles like it.iv>border-left:1px #ccc solid;padding-left:1ex;">
Finally, thank you for adding this setting. I enjoy exploring these puzzles=
.
from the initial release, and I've been looking forward to the time whe=
n the topic would get discussed ever since. =A0So thank you for exploring t=
hings and providing such valuable feedback! =A0The timing is good, as I'=
;m in the process of a full rework of the code for v2. =A0
n might look at someone who can solve the Rubik's Cube... =A0with awe!<=
/div>
--000325559986c2b81b049e68d52b--