Generated code for composites of C-set subparts

[epatters]

Composites of C-set subparts can be accessed using

subpart(x, i, [:f, :g])

Because the list of subparts is a vector, it must be map-reduced at runtime. We should also support a static version, based on tuples, that @generates code:

subpart(x, i, (:f, :g))

Likewise for the function incident.

This is motivated by AlgebraicJulia/Catlab.jl#371, where composites of length 2 are used often in the implementation of DWDs as ACSets. When this feature is implemented, all the DWD code should be updated accordingly.

[slwu89]

@epatters I am working on addressing this (for both subpart and incident) at the moment. During that work, I noticed that incident(acs::StructACSet{S}, ::Colon, f::Symbol) does not return anything if f corresponds to an attribute rather than a morphism between objects. The reason is that the following code doesn't return the values stored in the Attribute (and by extension, neither does codom_parts). Is this intended behavior? If it is not, I am happy to address it in the course of working on this issue.

julia> datcomp
CompositesData{Symbol} {X:5, Y:4, Z:3, W:3, Zattr:0}
┌───┬───┬───┐
│ X │ f │ h │
├───┼───┼───┤
│ 1 │ 1 │ 1 │
│ 2 │ 2 │ 2 │
│ 3 │ 3 │ 3 │
│ 4 │ 1 │ 1 │
│ 5 │ 2 │ 2 │
└───┴───┴───┘
┌───┬───┐
│ Y │ g │
├───┼───┤
│ 1 │ 3 │
│ 2 │ 2 │
│ 3 │ 1 │
│ 4 │ 3 │
└───┴───┘
┌───┬───────┐
│ Z │ zattr │
├───┼───────┤
│ 1 │     a │
│ 2 │     b │
│ 3 │     c │
└───┴───────┘


julia> parts(datcomp, codom(acset_schema(datcomp), :zattr))
1:0

[epatters]

Thanks for working on this, Sean!

I am wondering what the intended behavior of, say, incident(g, :, :weight) when g is a weighted graph, should even be. The colon usually means "all of the elements of a list/FinSet" but the attribute type is effectively infinite. Did you have something in mind?

[slwu89]

Ah I was thinking that : was returning elements in the codom that were hit by the function. But on second thought the current interpretation makes much more sense and avoids strange issues.

[jpfairbanks]

My first reaction to incident(g, :, :weight) is that it it should be like {y => incident(g, y, :weight) for y in g[:, :weight]} because the codomain of :weight is infinite, you can't return the whole inverse function, only the sparsely defined part. And since the codomain of :weight isn't canonically isomorphic to 1:n, you shouldn't return a list like[incident(g, y, :weight) for y in g[:, :weight]]. So either a list of pairs or a Dict makes the most sense to me.

[slwu89]

@jpfairbanks that makes sense, although I wonder if that would introduce too much complexity into the possible types of outputs from incident. And what should happen if someone did incident(g, :, [:src,:weight])?

[jpfairbanks]

I think the composite case should be handled by asking, what would I do with the composite function and then decide how to implement that. I would expect a map from each weight in the image of src;weight to the set of edges whose src has that weight.

[slwu89]

Great! that's what I ended up doing in #109, for composites. Didn't change anything for the single attr (arrow into typeset) case.

[slwu89]

I think this one is good to close since #109 is merged, however @jpfairbanks did bring up the interesting point of what should happen when someone does incident(g, :, :weight), so I don't know if we want to rename the issue and keep it around for that discussion, or close this issue and move that elsewhere.

[epatters]

IMO, that should be a separate issue, although you could link the discussion here if helpful. Thanks for closing a longstanding issue with acsets!