Message #3957

From: Roice Nelson <>
Subject: Re: [MC4D] Re: Cooperative Solving of Large Puzzles
Date: Mon, 15 Jan 2018 11:52:51 -0600

I personally have no issue with multiple individuals getting listed
together as the first solve. It’s kind of like the "Polymath
<>" projects, which are collaborative math
efforts where all participants get listed as authors on resulting papers.
It may be that no individual will ever be masochistic enough to tame the
cell-turning 600-cell their own, whereas I could see a polypuzzle effort
making such solves a possibility.

I like what Nan laid out in terms of mechanisms because it doesn’t require
new software development. It’s interesting that it does require making the
solve abelian, that is the macros used will need to commute. I think this
may mean the solution will be solving the commutator subgroup
<> of the full puzzle

The biggest immediate hurdle seems like it’d be garnering enough interest
and getting a solution group going, and finding a leader to keep things


On Sun, Jan 14, 2018 at 8:26 PM, Luna Peña
[4D_Cubing] <> wrote:

> This reminds me of FMC strategies, with commutator insertions and that
> sort of stuff. I think it would totally be possible. I don’t know how I’d
> feel about it counting as the first solve, but so long as the first person
> to do it alone got recognition, that seems reasonable.
> ~Luna
> On 15 Jan 2018 02:21, " [4D_Cubing]" <
>> wrote:
>> The first puzzle that comes into my mind is the full cell-turning 600
>> cell. Andrey included it in MPUlt in 2011.
>> It has 259800 stickers. Later on, Andrey created a simplified version,
>> keeping only about 2000 stickers. In today’s MPUlt, the "600-cell puzzle"
>> is only the simplified one. But one should still be able to create a config
>> to run the full version.
>> I don’t think anyone has attempted the full 600-cell.
>> I think the cooperative solving idea is possible. Many people can work on
>> isolated areas. For example people can divide piece types, and use macros
>> that only affect their own types.
>> To track progress, we can have the solution and macro definition files in
>> a git repo, assuming macro move takes one line in such files. One can
>> branch from master, work on their piece types, send pull requests and
>> carefully merge back to master. There should only be line insertions in the
>> merge but no modification.
>> We may also have some scripts to track the percentage of solved pieces in
>> each type, to guard us from making bad merges. In any case, we can always
>> go back to an old commit. I used such scripts to track some of my big
>> solves, but working alone, I never have to create branches.
>> Does this approach sound reasonable?
>> Nan