Message #3959
From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Re: Cooperative Solving of Large Puzzles
Date: Mon, 15 Jan 2018 10:52:30 -0800
Out of the interested participants, some could potentially work together over wi-fi while taking buses and trains to work. A suitable leader might then be able to generate a commuter subgroup.
I’ll see myself out.
-Melinda
On 1/15/2018 9:56 AM, Luna Peña scarecrowfish@gmail.com [4D_Cubing] wrote:
>
>
> For me it’s less that a group might get listed as first, because they’d deserve it, but it’s just that someone might be solving it all alone, and then suddenly they’re beaten to it by a team all working together, you know? But it’s not that important really.
>
> I’d be up for joining in with a solve, depending on the time. (Although I can’t run Andrey’s puzzles right now 🙃)
>
> ~Luna
>
> On 15 Jan 2018 17:53, "Roice Nelson roice3@gmail.com <mailto:roice3@gmail.com> [4D_Cubing]" <4D_Cubing@yahoogroups.com <mailto:4D_Cubing@yahoogroups.com>> wrote:
>
> I personally have no issue with multiple individuals getting listed together as the first solve. It’s kind of like the "Polymath <https://polymathprojects.org/>" 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 <https://en.wikipedia.org/wiki/Commutator_subgroup> of the full puzzle group.
>
> 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 moving.
>
> Best,
> Roice
>
>
> On Sun, Jan 14, 2018 at 8:26 PM, Luna Peña scarecrowfish@gmail.com <mailto:scarecrowfish@gmail.com> [4D_Cubing] <4D_Cubing@yahoogroups.com <mailto:4D_Cubing@yahoogroups.com>> 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, "mananself@gmail.com <mailto:mananself@gmail.com> [4D_Cubing]" <4D_Cubing@yahoogroups.com <mailto:4D_Cubing@yahoogroups.com>> wrote:
>
> The first puzzle that comes into my mind is the full cell-turning 600 cell. Andrey included it in MPUlt in 2011.
>
> https://groups.yahoo.com/neo/groups/4D_Cubing/conversations/topics/1745 <https://groups.yahoo.com/neo/groups/4D_Cubing/conversations/topics/1745>
>
> 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
>
>
>
>
>
>
>