Thread: "MC5D solution posted"

------=_Part_43753_20125234.1147765089084
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hey guys. I finished my MC5D solution tonight and went ahead and posted
it. It ended up taking a little over 6000 moves, so it takes forever to
play back. But it is kind of fun to play with the projection parameters
while it is doing so :)

Also, I found there is a small bug when you first complete a solution that
can mess up the last move in your log file. I'll fix this tomorrow, but
wanted to let you guys know. If any of you are working on solutions, you'l=
l
want to grab the new install I'll (probably) post tomorrow evening.

Roice

------=_Part_43753_20125234.1147765089084
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hey Roice,

Good job :-)

Any surprises?
What did your macros look like?

Here are some average solution lengths
given by my solve program on a 100-twist scramble...
this might give some idea of the relative difficulty of the 3^6.
Each new dimension seems to multiply the solution length
by roughly 6 (using this program's algorithm, it may be different
for other algorithms).

3^3: 251
3^4: 1738
3^5: 10108
3^6: 60896
3^7: 360000
3^8: crashes my java VM

However, the ideas are recursive--
so, assuming you can make macros out of other macros,
I bet the 3^6 would really not be significantly
harder than the 3^5, once you get the user interface going :-)
I don't think there are any conceptual surprises after 5 dimensions.

Don

On Tue, May 16, 2006 at 02:38:09AM -0500, Roice Nelson wrote:
> Hey guys. I finished my MC5D solution tonight and went ahead and
> posted it. It ended up taking a little over 6000 moves, so it takes
> forever to play back. But it is kind of fun to play with the
> projection parameters while it is doing so :)

--
Don Hatch
hatch@plunk.org
http://www.plunk.org/~hatch/

------=_Part_8154_13480880.1147847262678
Content-Type: multipart/alternative;
boundary="----=_Part_8155_13628290.1147847262678"

------=_Part_8155_13628290.1147847262678
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Cool, I had been curious what solution lengths it would produce. I haven't
downloaded the required stuff to compile this yet, but Charlie did already
start playing with how to get it into MC5D :) It looks like you have
improved the original perl script you did (I think I remember that having
average solution lengths around 3000 for the 3^4 case). It is remarkable
how well a factor of 6 predicts solution length!

To answer your first question, there were little surprises here and
there, most related to generalizing the corner sequence. I tried for a
little bit to find a sequence that didn't twirl a 4th piece, but gave up an=
d
decided to trudge along with the one I had. After you last email, I could
see my 5-colored sequence coupled with another sequence to undo the twirl
would have the effect I was looking for, but I didn't bother making such a
sequence. It would have added a bunch of extra twists and I was already
about 1/2 way through the corners at the time anyway. An interesting thing
about the corner sequence I used is that although it only cycles 3 pieces,
you actually have to run it 9 times to get it to cycle everything back to
it's starting point (the twirled piece does return to it's original state
every 3 runs). This is different than sequences I've used in the past,
which normally cycle back after just 3. The only other new scenarios I can
remember were 4-colored pieces doing things they couldn't in the 4D case (I
could reorient to swap just 2 of the 4 stickers for instance), but
these made more sense straight away because it could be expected the extra
space would allow it. Another comment I had is that the 3^5 didn't get har=
d
until the end. Because of all the space of the dimensions, moving around
and reorienting the more "central" pieces (2-coloreds and 3-coloreds in
particular) was not bad. Only when I got to the corners did the pieces
start getting restricted by the full puzzle dimensions, and so I began
finding preliminary moves more difficult.

But all in all, since the ideas are recursive as you said, it was pretty
much the same as MC4D. So I agree a 3^6 wouldn't be terribly more
difficult, just *so much* longer. I don't think it would be very fun
though! I had made a spreadsheet last week counting the number of types of
pieces for a 3^d puzzle, and it just starts to get really large. I had
thought it interesting to make these counts, even if not terribly relevant
for any practical purpose, but after seeing your program maybe it does have
some practical relevancy :) I went ahead and wrote up an explanation about
it tonight (posted at www.gravitation3d.com/magiccube5d/anatomy.html). It'=
s
a little basic at the beginning, but I tried to write it for people who
might be getting exposed to it for the first time too.

To answer your second question, I attached the macro file I used. The
"swap" and "cycle" macros aren't main sequences, just helpers that were
useful to me for preliminary moves. The other main sequences were very
quick to generate. To make the next higher one, I just used the previous.
So e.g. to get a 4-colored macro, I'd do:

3-colored macro
a twist
undo 3-colored macro
undo twist

etc. making my main sequences length 8, 18, and 38. I know there are
shorter versions of the latter 2 (16 and 32 length probably), I just didn't
bother finding them. You can't see this recursion in the macro files
themselves though since they just record all the twists.

One last thought. I made a "full scramble" on the 3^5 60 twists, which
looked plenty scrambled visually. I actually tried less and it still looke=
d
scrambled enough, but I figured the more the better. I mention this becaus=
e
I wonder at what dimension 100 scrambles wouldn't be enough. I guess it
could be checked with an additional function in your code which checked how
many pieces are left unaltered by a given scramble.

Roice

P.S. I did upload a new version this evening with that bug fix if anyone
wants to grab it. You won't want your solution to be spoiled at the last
minute ;)


On 5/16/06, Don Hatch wrote:
>
> Hey Roice,
>
> Good job :-)
>
> Any surprises?
> What did your macros look like?
>
> Here are some average solution lengths
> given by my solve program on a 100-twist scramble...
> this might give some idea of the relative difficulty of the 3^6.
> Each new dimension seems to multiply the solution length
> by roughly 6 (using this program's algorithm, it may be different
> for other algorithms).
>
> 3^3: 251
> 3^4: 1738
> 3^5: 10108
> 3^6: 60896
> 3^7: 360000
> 3^8: crashes my java VM
>
> However, the ideas are recursive--
> so, assuming you can make macros out of other macros,
> I bet the 3^6 would really not be significantly
> harder than the 3^5, once you get the user interface going :-)
> I don't think there are any conceptual surprises after 5 dimensions.
>
> Don
>

------=_Part_8155_13628290.1147847262678
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline