Local Multiway System research page

[maxitg]

Changes

• Closes Local multiway system description #334.
• Adds a research page explaining how the local multiway system works, and showing some examples for both match-all and spacelike multiway systems.

Comments

• This is a "living" document, and it will be improved in future PRs. Anybody can contribute, even if they are not the original author. For example, it will be updated once the progress is done on local isomorphism (see future research section).
• The purpose of this pull request is essentially a peer-review of this bulletin. Feel free to leave comments for both the physics content, the system description, as well as small/technical comments about the explanation.
• If you are not a SetReplace collaborator, you can still comment below.

Examples

• Read the rendered version.

---

This change is 

[elshatlawy]

Reviewed 20 of 20 files at r1.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @aokellermann and @taliesinb)

[JustinHedge]

Is there anything trivially impeding a distributed/parallel port of this wrapper, or at least enhancing efficiency in some order of magnitude tied to local GPU usage? Quite ironic that I should be able to deduce the answer myself from this work, if I understood a bit more about how to frame the question.

[maxitg]

Is there anything trivially impeding a distributed/parallel port of this wrapper, or at least enhancing efficiency in some order of magnitude tied to local GPU usage? Quite ironic that I should be able to deduce the answer myself from this work, if I understood a bit more about how to frame the question.

No, not really. In fact, it's easier to implement for the multiway system because one does not have to worry about synchronizing event order (as one would have to do in a case of deterministic singleway evolution). Here is the relevant project.

[taliesinb]

Reviewable seems to be down for me... so I'll just quote text for now. To be honest, I find the final section a little but unclear.

This isomorphism testing can be done by considering every pair of sub-evolutions starting from the same inputs. Suppose their outputs are identical up to the renaming of new atoms. In that case, we can identify the resulting expressions so that the two branches end at the same set of expressions, even if the intermediate steps are different.

This is not clear enough that I can understand it. To understand a "pair of sub-evolutions" I need to understand a "sub-evolution"? Is a sub-evolution defined somewhere formally? Local multiway systems are quite unintuitive objects, and it is maybe misleading to think about them directly. An evolution in a local multiway system is quite non-local, for example these are all evolutions of a simple expression event graph:

In the example above, we will then get:

How will we get the graph you depict? By applying the "pair of sub-evolutions" algorithm you describe? If indeed you have a particular algorithm, then how can it be "[un]clear exactly how one should identify".

Also I suggest saying 'deduplicate' rather than identify here.

[taliesinb]

Another comment that is not a criticism, just more of a suggestion.

I do find the Mathematica-produced graphs to perhaps be less clear than hand-drawn graphs could be. The advantage of hand-drawn graphs is that you can use arrows, highlighting, text, etc. in a way that is too cumbersome to set up with Mathematica. Also, Mathematica's graph drawing tends to be wildly inconsistent in scale in a way that I find highly distracting and ugly (see the graph above "The current implementation of the local multiway system does not do that" for a good example of this).

Of course drawing is too painful if one does not have an iPad and Apple Pencil or similar input device. But I can recommend the application Affinity Designer as a high-quality vector drawing program for both iPadOS and MacOS / Windows.

[maxitg]

evolution in a local multiway system is quite non-local

Can you explain in what sense are they non-local? Other than that, I expanded the description of both the deduplication algorithm and the example a bit so that hopefully they are more clear now.

[maxitg]

Another comment that is not a criticism, just more of a suggestion.

I do find the Mathematica-produced graphs to perhaps be less clear than hand-drawn graphs could be. The advantage of hand-drawn graphs is that you can use arrows, highlighting, text, etc. in a way that is too cumbersome to set up with Mathematica. Also, Mathematica's graph drawing tends to be wildly inconsistent in scale in a way that I find highly distracting and ugly (see the graph above "The current implementation of the local multiway system does not do that" for a good example of this).

Of course drawing is too painful if one does not have an iPad and Apple Pencil or similar input device. But I can recommend the application Affinity Designer as a high-quality vector drawing program for both iPadOS and MacOS / Windows.

I cannot say I agree. The advantage of using computer-generated graphs is that it is clear what code is needed to generate them. It also proves that they are correct (at least so far as the code is correct).

In addition, hand-drawing is limited to small graphs. If one needs to have examples of large graphs in the note, they would have to look different, which would make it inconsistent.

With respect to the graph you mention, do you think the ImageSize should be reduced?

Just to be clear, I'm not saying it never makes sense to use hand-drawn pictures, but I do think given that all but three of the graphs here are auto-generated from evolution code, it makes more sense to produce them with code here.

[taliesinb]

This is much clearer, I know understand immediately the point being made! Thanks.