Ensuring consistency between successive diagrams about penrose HOT 5 OPEN

Thanks for writing this up @liangyiliang!

For a basic, non-group shape, I think this involves walking through all numerical properties of the shape, and recursively looking for ad.Var. For group shapes we need to walk through all sub-shapes too.

I think computeShapes gives you Shape<number>[], so you probably can't find the ad.Vars there. Other related functions such as genCode also don't give you the information. You'd need to manually accumulate this info from the Style compiler. Also tagging @hsharriman for visibility.

from penrose.

Proposal

The user would first input Substance program sub1. After Penrose generates the diagram for sub1, the user would then provide sub2 (which would presumably be modified from sub1). When Penrose generates the diagram for sub2, the expected behavior is:

• shapes that are associated with both sub1 and sub2 would be "frozen"
• shapes that are associated with sub1 but not associated with sub2 would be removed
• shapes that are not associated with sub1 but associated with sub2 would be added and allowed to freely change.

Since shapes are defined by their properties which may refer to varying values, we can't really "freeze" a shape without freezing the underlying varying values. So we actually care about the varying values that are associated with the shapes which are then associated with the Substance program.

Association between Varying Value and Shape

A shape is defined as a set of properties, each of which may refer to some varying values. Given a shape, we would need to extract the varying values that are used, by any means, in the shape. For a basic, non-group shape, I think this involves walking through all numerical properties of the shape, and recursively looking for ad.Var. For group shapes we need to walk through all sub-shapes too.

Association between Shape and Substance

A shape is "associated with" a Substance program iff it is associated with some statement(s) in the Substance program. In this case, we are only interested in statements in the post-compilation version of the Substance program (CompiledSubProg) where all declaration-lists (DeclList), declaration-binds (DeclBind), and indexed sets are flattened. Doing so allows us to only consider single object declarations (Decl), object bindings (Bind), and predicate applications (ApplyPredicate).

Given a Substance statement, we thought of two ways where a shape can be associated with a Substance statement.

Association by path: If we have Substance object x (or predicate application, since predicates can have aliases), then a shape is associated with x iff the shape is named `x`.some_name. This defines association as "belonging" -- `x`.some_name belongs to x.

Association by causation: If the shape is generated as a result of matching upon a Substance statement, then that shape is associated with the statement. As an example, if this Style program

forall Node x, y
where e := MkEdge(x, y)
with Edge e {
  icon = Line { ... }
}

is activated, then the Line shape would be associated with the Substance instances of x, y, e (these are declarations), and e := MkEdge(x, y) (as a relation).

We would preferably want both forms of associations.

Note: My intuition is that association by causation already implies association by path, since if we can define a shape with name `x`.some_name, then we must have matched on the Substance object x. Is that true? If so, we won't need association by path.

from penrose.

You'd need to manually accumulate this info from the Style compiler.

Doesn't State.shapes provide you a list of Shape<ad.Num>?

from penrose.

@eskang and @keenancrane It would be great if you can provide comments or ask questions on this issue.

from penrose.

You'd need to manually accumulate this info from the Style compiler.

Doesn't State.shapes provide you a list of Shape<ad.Num>?

You're probably right. Note that State.shapes isn't really used much, perhaps nowhere other than collectLabels. Give it a try and see if you can match up shape properties with varying values by strict equality (===).

Double-checking with @samestep: does this sound reasonable?

from penrose.