Multigraphs via an edge index and edge properties/metadata#81
Open
zblanco wants to merge 18 commits intobitwalker:mainfrom
Open
Multigraphs via an edge index and edge properties/metadata#81zblanco wants to merge 18 commits intobitwalker:mainfrom
zblanco wants to merge 18 commits intobitwalker:mainfrom
Conversation
This reverts commit 8a23cd3.
Contributor
Author
|
I've been using this PR inside https://github.com/zblanco/runic for some time now as a way to keep causal runtime edges produced during DAG executions from increasing the dataflow traversal costs. It hasn't need changes and tests pass for 1.18 and might be worth reviewing. I developed this locally on Elixir 1.18+ which entailed some changes to doctests related to ordering of some results but this leaves older versions broken in CI. Not 100% on a preferred course of action - I would rather find a way to keep older versions compatible so that's what I'm looking into now. This test discrepancy may be related to OTP updates as it's not related to the actual changes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An effort to implement #18 as well as #54 for some of my own use cases. Looks like some planning work went into these in the past so not sure if there's a more preferred approach for multigraphs and/or adjacency indexing.
Ran into a performance use case for multigraphs where to minimize enumeration on traversals for I wanted an index to trade space for time.
Current approach
An opt-in flag
Graph.new(multigraph: true)with options for using a partitioned adjacency index in reflection APIs (out_edges, edges, in_edges, etc).By default this option will maintain an adjacency index partitioned by the edge label. This is overrideable with the
:partition_byoption which accepts and edge and returns a partition. E.g.Graph.new(multigraph: true, partition_by: fn edge -> edge.weight end)Reflection API options:
:by: a term or list of terms containing the partition keys.:where: a filter function which accepts an edge and returns a boolean to include or exclude it from the result.The
edge_indexis implemented as a nested map%{partition => %{vertex_id => Mapset(edge_keys)}}so the:byoption can use map access time to get the set of adjacent edges for one or more partitions.Edge Properties
For metadata / edge properties this PR changes the edge value from
%{label => edge_weight}toas well as adding the
propertiesmap to the%Edge{}struct.Todos:
fn %{label: label} -> label endto return the key