Message #2146

From: Melinda Green <>
Subject: Re: [MC4D] Re: Edge turning {3,7} IRP solved
Date: Sat, 12 May 2012 02:51:44 -0700

On 5/12/2012 1:28 AM, schuma wrote:
> I like the feature of "randomly generating colors". It would be useful in solving. An example is the situation that Melinda met. She knew two colors along an orbit are identical or very similar, but to find out which two colors took some time. If there’s a "randomize colors" button, those two colors will pop out immediately.

What a great idea, Nan! I was only suggesting that Roice consider just
using my random function once per puzzle but I really like your idea to
let the user randomize at any time!

Roice: I’ve also noticed that the settings sometimes all reset as a
result of switching puzzles which seems like a small bug. It may have
something to do with using two instances of MT at the same time. I’m not

> I have also solved this puzzle (IRP {3,7} 56-color E0:1:0). I solved it in the IRP view.

Now how the heck did you do that, Nan?! And using less than at third of
the twists that I used! I love the 3D geometry of this one probably more
than any other IRP but it just seemed impossible to solve it in that
mode. Your result seems like you did it one-handed and blindfolded. How
did you go about that and was it like to solve it that way?

> There are 168 small pieces that actually move. I THOUGHT they were divided into 7 orbits, each of which has 24 pieces. But I was wrong. There are four shorter orbits, each with 6 pieces. Sum of them = 24. So it seems there are 6 longer orbits with length 24, and 4 shorter orbits with length 6.

That’s pretty cool, isn’t it? This was one of the features that I want
to emphasize in that sculpture I mentioned earlier.

> The four shorter orbits are as follows (I’m writing only the first two colors because the rest are determined)
> 1. triangles with colors 8 - 18 - …
> 2. triangles with colors 20 - 9 - …
> 3. triangles with colors 46 - 53 - …
> 4. triangles with colors 29 - 25 - …
> In the image of this page:
> The four short orbits are around the "necks" colored by blue, red, green and a blocked (thus unknown) color. So the faces and edges are actually not equivalent. I consider it a generalized "deltahedron"
> []
> After I read more about the infinite polyhedra/skew polyhedra on wikipedia, I found Coxeter and Petrie considered the most stringent regularity, just like "regular" polyhedra. And there are only three "regular infinite skew polyhedra".
> Gott relaxed it to include more shapes, including {3,7}. "Where Coxeter and Petrie had required that the vertices be symmetrical, Gott required only that they be congruent" [].
> On this page:
> "Regular polyhedra are those that are composed of only one type of regular polygon", therefore no requirement on vertices.

That’s my page and I’m surprised that I didn’t really mention vertices.
For the definition that I prefer, all faces must be the same regular
polygon and all vertices must be transitive. The one constraint that I
relax from true regularity is that the edges do not need to be identical
which implies that the faces aren’t necessarily transitive. I should
clarify that.

> There are more IRP puzzles, e.g., {4,5} 30C, with non-equivalent faces and maybe orbits with different lengths, waiting for us to discover.

I was in the middle of solving the edge turning version of that one when
your message came in! :-)

There is also at least one puzzle in which paths loop around and crosses
itself kind of like the shape of the number 6. Because of that you can
move a petal from one corner of a triangle, sending it out around its
orbit only to come back in such a way that you can place it into a
different corner of the triangle that it came from. The orbit must loop
around three times like that like a Celtic triangle
<>. I’ll
let you figure out which puzzle that is. :-)


> — In, Melinda Green<melinda@…> wrote:
>> Yes, that was it. I also adjusted another pair that was distinct but
>> very close. Maybe orange and 255,128,0?
>> You may like to look at the generateVisuallyDistinctColors method I
>> wrote for MC4D which I’m rather proud of. It finds N colors as different
>> from each other as possible in the YUV color space and with the
>> restriction that within each color, at least one component of its RGB
>> equivalent is greater than a given minimum and one that is less than a
>> given maximum. One of the best things about using a dynamically
>> generated list is that those cases that need fewer colors (the common
>> cases) will have more freedom to choose more contrasting colors than
>> those which require more.
>> -Melinda
>> On 5/11/2012 10:01 AM, Roice Nelson wrote:
>>> Nan found some double colors early on in the defaults, which were
>>> corrected. Looks like this latest one must be color 7, "Cyan" and
>>> color 27, "Aqua". Different names, but visually they look identical
>>> to me. I’ll try to pick a better default for color 27, and please let
>>> me know if these weren’t the ones that caused the confusion.
>>> Thanks!
>>> Roice
>>> On Fri, May 11, 2012 at 2:16 AM, Melinda Green
>>> <melinda@…<mailto:melinda@…>> wrote:
>>> Oh, so that’s what you meant! Roice had reminded me about your
>>> "aha" but we thought you might have meant something else. So it’s
>>> just a bug in the default colors? It sure drove me batty for a
>>> while but I’m glad that I thought to check the colors.
>>> Your puzzle was the edge turning {4,4|3}, one of the "Harlequin"
>>> puzzles which are really the direct cousin of this one. By the
>>> way, toggle the "show as skew" setting for this one. It’s really
>>> quite amazing.
>>> -Melinda
>>> On 5/10/2012 11:47 PM, Eduard Baumann wrote:
>>>> The doubled cyan color! This was my "AHA" I mentioned enigmaticly
>>>> in the comment of a smaller case.