# 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

>

>