Thread: "ClojureScript scrambler and some ideas about a"

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

--000000000000dc92c705726ad426
Content-Type: multipart/alternative; boundary="000000000000dc92c505726ad425"

--000000000000dc92c505726ad425
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 >,
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!

- Andy

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
>
>=20
>



--=20

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

--000000000000dc92c505726ad425
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marc,

Thanks for the detailed respon=
se! My scrambler app is hosted by Github Pages at=C2=A0actarce.github.io/2x2x2x2-Scrambler/" target=3D"_blank">https://hactarce.gi=
thub.io/2x2x2x2-Scrambler/=C2=A0(link is also in the description a=
t the top of the repository). To host it yourself, clone the=C2=A0e=3D"monospace, monospace">gh-pages=C2=A0branch. The code is complet=
ely CLJS right now, but some slight refactoring to CLJC=C2=A0could make the=
whole thing Clojure-compatible, and thus JVM-compatible, as well. I have a=
bsolutely zero experience writing desktop programs using Clojure. (If Java =
GUI frameworks are painful in Java, I can only imagine the nightmare of thr=
owing CLJ-Java interop on top.) I think the most promising option would be =
to use Electron, =
allowing a single application to run both on browsers and on desktop.

=

I've never heard of KSolve+ before. I'm concern=
ed 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 permut=
ations, if my calculations are correct). Even each of the megaminx files us=
es a highly restricted move set.

I watched your pr=
oof-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 t=
he 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 progra=
ms, however, remain conveniently unconstrained by rigid 3D geometry. A prog=
ram could cleverly morph 3-color pieces into different shapes as the puzzle=
moves. Hopefully I'm making sense? Details can be ironed out later; th=
e point is that I'm pretty sure it's possible. Here's how 2-col=
or and 3-color pieces might look when stationary:

=

"169" style=3D"margin-right:0px">

I agre=
e 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 e=
xisting code and implementing the 3-stage algorithm I'll start on an in=
teractive physical 2^4 sim (again in CLJS, which supports interop with JS i=
n 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 l=
ike it would be the hardest part.

This is all =
very interesting!

- Andy