You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @epatters, following up here from the zulip conversation. Before working on PropertyBipartiteGraph and to_graphviz for it, I wanted to ask if you can help explain the design considerations behind the existing PropertyGraph machinery and its interaction with the other graph acsets/to_graphviz system, so that I can replicate as much as possible those designs for the bipartite one. And if there are any essential desiderata for the bipartite one. Thanks!
The text was updated successfully, but these errors were encountered:
This is relevant because in my current design I follow the version for basic graph property graph. That is, the type of the acset graph in the struct PropertyGraph should be a subtype of HasGraph. If I do something similar for bipartite graphs and make the type of the bipartite acset in BipartitePropertyGraph be a subtype of HasBipartiteGraph, the methods for remove vertices won't "forward" properly, as the type class is too wide for those ones.
I suspect that the intention was to have those methods in the BipartiteGraphs module actually take HasBipartiteGraph as the type of the first argument, but want to confirm with you.
Hi @epatters, following up here from the zulip conversation. Before working on
PropertyBipartiteGraph
andto_graphviz
for it, I wanted to ask if you can help explain the design considerations behind the existingPropertyGraph
machinery and its interaction with the other graph acsets/to_graphviz
system, so that I can replicate as much as possible those designs for the bipartite one. And if there are any essential desiderata for the bipartite one. Thanks!The text was updated successfully, but these errors were encountered: