Thread: "Newbie queries on Magic Tile - Klein Rubik"

--94eb2c190d8a2b0b1305423fcfe9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Welcome Ben!

*Question #1...*

A few things are contributing to the confusing behavior. This puzzle will
always have some weirdness because the map of faces on the surface is not
regular. If anyone wants to research this topic, the term to search is
"regular map" and I recommend Marston Conder's page
, which has lists and links to
papers, as well as visualization work by Jack van Wijk
and others
.
Regular maps on surfaces behave like platonic solids, in that every
face/edge/vertex acts like every other. This is not the case on the Rubik
Klein Bottle. For example, compare the repeating pattern of the white and
blue faces as you move over the tiling diagonally up and toward the right.
The white face repeats every 3 steps, while the blue face repeats every 6.
This non-regularity means that macros will behave differently when applied
in different positions or orientations. I'm not aware of a proof that
there is no regular map on the Klein bottle, so maybe one is possible.

Another complication here is the non-orientability of the surface. For
instance, if I manually do the set of moves you wrote out on the tiles in
the fundamental domain, the result is that nothing changes. But if I
manually perform those twists on mirrored tiles (so that CW/CCW sense is
reversed), I get a 3-cycle. So "Green CCW" is not descriptive enough in
the case of this puzzle - it depends on which green face you clicked!

Issue 13 and the details therein only make things worse. The problem there
is that the macro is getting defined as if the user clicked the identified
faces in the fundamental region rather than the particularly clicked
faces. This exacerbates both the non-regularity and the
non-orientabililty effects. I'm not sure but until that is improved, it
may be helpful to have the "Show Only Fundamental" option set to true when
defining macros.

I'm surprised to hear you are getting different results by clicking
different locations within a single facelet (assuming facelet means
sticker). If you stick to corner stickers for macro definition points,
that shouldn't be a problem. If you want to describe more detailed
reproduction steps to me privately, I'm happy to try to help understand
what is going on there.

One final comment on this topic is that macros can still be really useful
even if you give up the ability to transform them over the tiling. On my
5^5 implementation, you can only define macros in a canonical position, and
no transformations are even supported.

*Question #3...*

This discussion does pop up every once and a while, see for example:

Edging closer to a physical 4D puzzle
2713>

Physical Realization of MC4D Revisited
654>

5D Cube
235>

I am definitely excited about new possibilities because of the recent mass
availability of VR hardware.

Cheers,
Roice


On Sat, Nov 26, 2016 at 3:38 PM, qqwref@yahoo.com [4D_Cubing] <
4D_Cubing@yahoogroups.com> wrote:

>
>
> I can't help much with your questions #1 and #3, but as for #2, about
> parities - one of the interesting things about the Klein Bottle (and some
> other non-orientable surfaces) is that corners can be mirrored, so that o=
ne
> sticker will be in place but the other two will be swapped. For example, =
if
> reading clockwise you expect yellow-red-blue (YRB), on a normal cube you
> could have RBY or BYR, but on a Klein Bottle you may also see YBR, BRY, o=
r
> RYB.
>
> Now here's the trick: mirroring the same corner twice in different ways
> will have the same effect as twisting it on a regular cube. That is,
> swapping stickers 1 and 2, then stickers 2 and 3, will do a 3-cycle of
> stickers. So one way to twist a single corner would be to mirror corners =
A
> and B, twist corner A (plus some other corner(s)), mirror corners A and B
> again, and then undo the twist. Now B is solved, but A will be twisted
> because there was a 3-cycle on its stickers in a way that is independent
> from the twisting steps above.
>
> --Michael
>
>
>=20
>

--94eb2c190d8a2b0b1305423fcfe9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable