Message #4151

From: Luna Harran <scarecrowfish@gmail.com>
Subject: Re: [MC4D] Non-associative "twisty" puzzles
Date: Sun, 30 Sep 2018 23:47:58 +0100

I don’t know of a way to construct the conjugate reliably, although there
must be some way.

My ‘method’ currently involves understanding i and j, and using either h,
i*h, j*h, or i*j*h (and inverses) when I can no longer progress, or
recognise a pattern.

As another note, it turns out the moveset (i,j,h,i*h,j*h) and their
inverses is sufficient to solve the puzzle without any extra composition.
Thanks to this I was able to write a solver for the puzzle, and I was able
to generate all 240 states from solved in only 6 moves. This kind of
removes the non-associative property of the puzzle, and I wonder if this is
always possible with any non-associative puzzle. Perhaps solving with this
moveset, or some other, larger one would be easier.

And yeah, I should have :D

~Luna

On Sun, 30 Sep 2018 at 23:21, mananself@gmail.com [4D_Cubing] <
4D_Cubing@yahoogroups.com> wrote:

>
>
> Hi Luna,
>
> I’m glad that you find it interesting. I’m curious about your way to
> reliably solving it, even though you don’t call it a method.
>
> Thank you for adding the power, conj, inv methods. I believe we should
> only help users when they know how to use generators and multiplication to
> get the outputs of these methods.
>
> It’s easy to see that the power method a**n is easily constructible from
> the generators, because one can keep multiplying "a" n times. I think inv
> is probably constructible, because I guess one can prove any element
> repeated enough times can eventually go to identity. And repeating one less
> time gives us the inverse. But one may explore for a while before finding
> it out.
>
> Is there an easy way to construct conjugate of any expression?
>
> We also need to clarify the order of operation when we introduce the new
> operations.
>
> Feel free to raise a pull request if you think your change is complete. I
> welcome refactoring as well.
>
> I actually see this Python implementation as a proof of concept. If we
> find a better and intuitive representation, we should switch to that. We’ll
> revamp the UI anyway. That’s why I didn’t pay much attention on how things
> look.
>
> Luna, I was surprised that you didn’t color the winning message. Haha.
>
> Nan
>
>