Message #4098

From: Andy F <legomany3448@gmail.com>
Subject: Re: [MC4D] ClojureScript scrambler and some ideas about a near-optimal solver (plus "Fourtega" variant and my solve video)
Date: Wed, 01 Aug 2018 22:47:26 -0400

Hi Marc,

Thanks for the detailed response! My scrambler app is hosted by Github
Pages at https://hactarce.github.io/2x2x2x2-Scrambler/ (link is also in the
description at the top of the repository). To host it yourself, clone the
gh-pages branch. The code is completely CLJS right now, but some slight
refactoring to CLJC could make the whole thing Clojure-compatible, and thus
JVM-compatible, as well. I have absolutely zero experience writing desktop
programs using Clojure. (If Java GUI frameworks are painful in Java, I can
only imagine the nightmare of throwing CLJ-Java interop on top.) I think
the most promising option would be to use Electron <https://electronjs.org/>,
allowing a single application to run both on browsers and on desktop.

I’ve never heard of KSolve+ before. I’m concerned that it might not be able
to handle the 2^4, since the largest examples it has are the 3x3x3 (~10^18
permutations) and 4x4x4 centers (~10^21 permutations, if my calculations
are correct). Even each of the megaminx files uses a highly restricted move
set.

I watched your proof-of-concept video on other physical n^4 puzzles, and
the only roadblock I can think of is how to present the colors and
orientation of each piece. The 2^4 takes advantage of the fortunate
coincidence that it’s possible to easily split a 3D cube into as many
symmetric and identical pieces as the number of hyperstickers on each
hypercubie of a 2^4. Higher puzzles have three other piece types to handle;
representing 1-color and 2-color pieces is fairly trivial, but the 3-color
pieces are problematic. Computer programs, however, remain conveniently
unconstrained by rigid 3D geometry. A program could cleverly morph 3-color
pieces into different shapes as the puzzle moves. Hopefully I’m making
sense? Details can be ironed out later; the point is that I’m pretty sure
it’s possible. Here’s how 2-color and 3-color pieces might look when
stationary:

I agree that a full-blown n^4 "physical" puzzle sim would be very cool.
Starting with 2^4 seems like the way to go for now. After cleaning up my
existing code and implementing the 3-stage algorithm I’ll start on an
interactive physical 2^4 sim (again in CLJS, which supports interop with JS
in both directions) if I still have the motivation. Designing the UI for
the puzzle – not just the display, but the operation of the puzzle –
seems like it would be the hardest part.

This is all very interesting!

On Wed, Aug 1, 2018 at 4:12 PM, Marc Ringuette ringuette@solarmirror.com
[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>
>
> Hi Andy! Great stuff. Code, even!
>
> I’m sure a number of us would like to try out your scrambler and any
> follow-ons you do. Any chance you’ll either host a web version, or
> compile it into a Java jar file, or (ideally) compile it to Javascript
> so it can run on anybody’s web browser? (But only if it’s fairly easy
> and doesn’t require a complete new set of libraries or something.) We
> can easily host a version on one of our websites if it’s just Javascript.
>
> You get style points from me, by the way, for doing an on-the-fly video
> solve from a fresh random scramble. Quite a contrast from the previous
> one from Jay, who could be heard saying things like "I’ll break up this
> block here" as he did his short and sketchy scramble. Just teasing
> you, Jay, I like your stuff too. ;)
>
> Your Kociemba-ish numbers seem on target, regarding solution spaces and
> how to possibly break up a solution into phases.
>
> Regarding solving code: the first thing I’ve had in mind to try is to
> make a definition file for the generic permutation puzzle solver Ksolve
> being maintained by Michael Gottlieb. It’s some C++ code that takes a
> puzzle definition file and a scramble file as input, and finds solutions
> to the scramble.
> http://mzrg.com/rubik/ksolve+/
> For example, here’s the definition file for a regular 3x3x3.
> http://mzrg.com/rubik/ksolve+/3x3x3.def
> Although, there’s a subtlety in using this for the 2x2x2x2 because of a
> limitation of the code: Michael suggests that a sticker-based version
> (where the pieces defined in the file are 64 stickers, not 16 4-color
> pieces) would work, but that the obvious version where 16 4-color pieces
> are permuted and oriented, would fail due to the assumption that twists
> can be added and subtracted commutatively modulo the number of
> orientations. Alternatively, I’ve spotted the place in the C++ code
> where this assumption could be generalized pretty easily. So, before
> anybody tries it, I suggest that you email back and forth a bit with me
> to give you a head start. The result of this pretty easy project would
> be very useful, but far less than ideal: a piece of executable C++ code
> that takes a text file scramble as input and spits out some solutions to
> it. It could then perhaps be wrapped in something more palatable, such
> as a link to MC4D or to a different interface as below, to become less
> painful to use.
>
> Regarding the code I’d most like to see written: a scrambler was on
> the list – good job there – but my biggest desire is for a (preferably
> Javascript based) virtual physical 2x2x2x2 puzzle. This would open up
> the puzzle to more interested people, by a factor of 100 at least! It
> would be absolutely huge. Of course, much less tactile and desirable
> than a physical puzzle, but far more accessible to all.
>
> The code I envision for a virtual physical 2x2x2x2 would be a lot like
> Roofpig from Lars Petrus, which is some nice Javascript code for online
> Rubik’s Cube demos.
> http://lar5.com/cube/index.html
> (click "play" on the cube animation on the right to see it in action; a
> link to the Roofpig code is at the top right of the page).
> However, glancing at the code, I see that Roofpig is very 3x3x3
> dependent. It would be a total rewrite, but perhaps a helpful place to
> start.
>
> Another piece of code that would be cool to see: a hugely simplified
> MC4D version, not a port at all, and once again preferably in
> Javascript, to solve only the n^4 hypercubes. It wouldn’t use the 4D
> projection code at all, but instead would show 3D cubical stickers
> flying around in a 3D workspace, analogous to how my sticker-based demo
> can be performed in real life. Since such a program would be 10x
> simpler than MC4D and would run in any browser, it could open up the n^4
> hypercube puzzles to more people also.
>
> Then, of course, we wire all three of these projects together with
> side-by-side automated physical and virtual 2^4 solvers, and … this is
> getting out of hand. ;)
>
> Cheers
> Marc
>
>
>

–

"Engineers like to solve problems. If there are no problems handily
available, they will create their own problems." - Scott Adams