Timothy Gowers’ Guidance On Massively Parallel Mathematics: Flocking, Again

Timothy Gowers is a Fields Award recipient, perhaps the highest honor in mathematics. He thought that massively parallel research-based collaboration might be possible on math problems, so he selected one, set relatively modest goals, and set off with a large sprawling swarm to test this idea (as I clipped recently from the NY Times):

1. It is not the case that the aim of the project is to find a combinatorial proof of the density Hales-Jewett theorem when . I would love it if that was the result, but the actual aim is more modest: it is either to prove that a certain approach to that theorem (which I shall soon explain) works, or
to give a very convincing argument that that approach cannot work. (I
shall have a few remarks later about what such a convincing argument
might conceivably look like.)

via Timothy Gowers A combinatorial approach to density Hales-Jewett

And then, he offered some guidance on how the collaboration might work, considering that it would involve more than two guys and a dog:

To finish, here is a set of ground rules that I hope it will be possible to abide by. At this stage I’m just guessing what will work, so these rules are subject to change. If you can see obvious flaws let me know.

1. The aim will be to produce a proof in a top-down manner. Thus, at least to start with, comments should be short and not too technical: they would be more like feasibility studies of various ideas.

2. Comments should be as easy to understand as is humanly possible. For a truly collaborative project it is not enough to have a good idea: you have to express it in such a way that others can build on it.

3. When you do research, you are more likely to succeed if you try out lots of stupid ideas. Similarly, stupid comments are welcome here. (In the sense in which I am using “stupid”, it means something completely different from “unintelligent”. It just means not fully thought through.)

4. If you can see why somebody else’s comment is stupid, point it out in a polite way. And if someone points out that your comment is stupid, do not take offence: better to have had five stupid ideas than no ideas at all. And if somebody wrongly points out that your idea is stupid, it is even more important not to take offence: just explain gently why their dismissal of your idea is itself stupid.

5. Don’t actually use the word “stupid”, except perhaps of yourself.

6. The ideal outcome would be a solution of the problem with no single individual having to think all that hard. The hard thought would be done by a sort of super-mathematician whose brain is distributed amongst bits of the brains of lots of interlinked people. So try to resist the temptation to go away and think about something and come back with carefully polished thoughts: just give quick reactions to what you read and hope that the conversation will develop in good directions.

7. If you are convinced that you could answer a question, but it would just need a couple of weeks to go away and try a few things out, then still resist the temptation to do that. Instead, explain briefly, but as precisely as you can, why you think it is feasible to answer the question and see if the collective approach gets to the answer more quickly. (The hope is that every big idea can be broken down into a sequence of small ideas. The job of any individual collaborator is to have these small ideas until the big idea becomes obvious — and therefore just a small addition to what has gone before.) Only go off on your own if there is a general consensus that that is what you should do.

8. Similarly, suppose that somebody has an imprecise idea and you think that you can write out a fully precise version. This could be extremely valuable to the project, but don’t rush ahead and do it. First, announce in a comment what you think you can do. If the responses to your comment suggest that others would welcome a fully detailed proof of some substatement, then write a further comment with a fully motivated explanation of what it is you can prove, and give a link to a pdf file that contains the proof.

9. Actual technical work, as described in 8, will mainly be of use if it can be treated as a module. That is, one would ideally like the result to be a short statement that others can use without understanding its proof.

10. Keep the discussion focused. For instance, if the project concerns a particular approach to a particular problem (as it will do at first), and it causes you to think of a completely different approach to that problem, or of a possible way of solving a different problem, then by all means mention this, but don’t disappear down a different track.

11. However, if the different track seems to be particularly fruitful, then it would perhaps be OK to suggest it, and if there is widespread agreement that it would in fact be a good idea to abandon the original project (possibly temporarily) and pursue a new one — a kind of decision that individual mathematicians make all the time — then that is permissible.

12. Suppose the experiment actually results in something publishable. Even if only a very small number of people contribute the lion’s share of the ideas, the paper will still be submitted under a collective pseudonym with a link to the entire online discussion.

via Timothy Gowers Is Massively Parallel Collaborative Mathematics Possible?

I find the list interesting, and I am convinced that much of the thinking here about large group innovation is general, not specific to the particular math problem involved, or math more generally. In particular, I think that his recommendations that an individual part of the swarm not go too far in one step — that a contributor should not develop a lengthy, multi-step proof of some large chunk of the problem, but instead should take small steps — is critical to understanding how this might work.

Connectedness trumps everything else: it is more important to have the group as a whole remain in sync, than for an individual to make a series of solitary insights. Otherwise, the natural tendency is for the swarm to break into bits, each one chasing promising leads, but perhaps not spending enough time transmitting tiny insights to others. Connections act as a conduit for information and as beacons, indicating where we are situated relative to others.

Biologists studying flocks of birds, schools of fish, and herds of antelope have discovered that a only a very small set of rules are needed for flocking to occur. Steering by animals in groups requires a fine sense of
where the others in the swarm are located, as well as what they are up
to:

Basic models of flocking behavior are controlled by three simple rules:

1. Separation - avoid crowding neighbors (short range repulsion)


2. Alignment - steer towards average heading of neighbors


3. Cohesion - steer towards average position of neighbors (long range attraction)

With these three simple rules, the flock moves in an extremely
realistic way, creating complex motion and interaction that would be
extremely hard to create otherwise.

via wikipedia

Most of Gowers recommendations seem to focus on alignment and cohesion, but point 8, for example, is about separation: one member should not jump onto another’s idea with a full proof until there is group support for that. It would be worthwhile to examine the list in detail from the perspective of the three rules of flocking, I bet.

It is noteworthy that Gowers and company, in the guise of D.H.J. Polymath, have solved the theorem in question, after only six weeks of massively parallel flocking.

I hope to be able to unearth more information about the way that the Netflix Challenge winners worked, or clues from other large-scale collaborative efforts.