nickhu / homotopy-io Goto Github PK

Currently, the best description of what is going on in homotopy.io is https://arxiv.org/abs/1902.03831. However, this is targeted towards an academic audience and is at a higher level of abstraction than what is going on here. It would be nice to have a less formal document which describes the components and how everything works together, and is more implementation-focused.

Add a README; give a brief overview of the build tools we are using

The dual to contraction - when you make a move like the following:

| |        | |
o o   ->   o |
| |        | o
           | |

This procedure is not natural and involves making arbitrary choices

Since we no longer have separate core and client repositories, the repository should just be called 'homotopy' or 'homotopy-io' or something.

A rewrite contains a list of cones. Suppose we have a list

c1 : c2 : c3 : Nil

There is a coordinate system describing these cones, with respect which their "index" parameter is defined. Clearly the index parameter doesn't vary arbitrarily along the list; it is either non-increasing, or non-decreasing, depending on the convention that we have chosen.

The question is whether c3 should have the smallest value of the index parameter, or if c1 has the smallest parameter. I believe it would make a lot of sense for c3 to have the smallest parameter, as that way the base case of recursion is sitting at the coordinate origin.

Nick and I discussed this today and we weren't completely sure which was intended. Lukas, can you confirm what the convention is?

It's important for everyone to be clear on the convention so that mistake aren't made. Note that the right-to-left convention that I'm hoping for above is in some sense counterintuitive to the normal expectation that the origin for the coordinate system should be "on the left", since the item c3 is at the right of the list as represented above, not at the left.

Expansion is almost ready to go, and I guess the same for contraction. It would be great to have the UI hooks in place so they can be tried out on nontrivial diagrams.

It would be good to discuss how memoization could work for the new codebase. The primary advantage would be to avoid creating duplicate instances of the main Diagram and Rewrite data structures. It may also be convenient to be able to cache other expensive quantities, like the slices of a given diagram, the computation of which can otherwise be a bottleneck during rendering. But getting this wrong could easily lead to too much being cached and excessive memory usage.

Contraction, as described here, is the big algorithmic part of this library

At the moment, we can build the PureScript code into JavaScript with spago build, but at some point someone needs to figure out what to do with the JavaScript output

After we do this, we can start thinking about continuous integration

We can probably start with just 2D for now

Why don't we define diagrams like this:

data Diagram = Diagram0 Generator | DiagramN Diagram (List Cospan)

I'm not saying I think this would be better, I'd just like to understand the design decisions.

The data structure needs to be decycled and deduplicated after every interaction.

(Not necessary for the initial working version.)

At the moment we store a dimension in RewriteN, but not in DiagramN. It would be good to discuss the rationale for that here. It could be that it's the right way to go, but it's not obvious to me.

One possibility is for both DiagramN and RewriteN objects to store dimension integers, for convenience. (Potential downside is that we're storing a lot of unnecessary information.)

Another possibility is to never store dimension integers, since they can always be computed for well-typed structures. (Potential downside is that it would then take O(n) to compute the dimension of an n-dimensional Diagram or Rewrite, as you need to track to the bottom of the syntax tree.)

Another possibility is for only one of DiagramN and RewriteN to store dimension integers. If we choose this path, it might be easier to store the dimension in DiagramN, and not RewriteN. One reason is that rewrites can be identities, which currently store no information at all, which seems nice to preserve. Another reason is that diagrams are the primary geometrical entities which we display. Another reason is that diagrams already store meta-information, like their source boundary, while rewrites don't, being sparse; so it's perhaps to natural to attach one more piece of meta-information to a diagram, than to a rewrite.

If I have a record object rec = { a : val1, b : val2, c : val3 }, how can get a shallow copy with specific field(s) updated?

In JS I would use a spread: { ...rec, a : newval }.

In Purescript it seemed to me that | is supposed to work similarly, i.e. rec | a : newval, but I can't seem to get it to work.

We need to implement the following:

• contraction on a singular level by composition;
• contraction on a regular level by "bubbling";
• expansion on a singular level by factorization or bubbling.

At the moment there is no UI, so I need some guidance as to how to create data structure instances interactively. For example, could someone tell me how to build this diagram:

| |
o o
| |