stevensonmt
When you use the :digraph module and want to get a list of all edges, one would expect to see a list of vertex pairs, ideally with the “emanate from” / “incident to” order consistent. So something like [{:a, :b}, {:b, :c}, {:c, :b}] for a graph with vertices [:a, :b, :c] where :a has an edge incident to :b and :b and :c have a bidirectional edge. Instead you might see something inscrutable like [[:"$e" | 0], [:"$e" | 1], [:"$e" | 2]]. How are you supposed to interpret that list?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Marked As Solved- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
Definitely an odd design choice - you could get something closer to what you’re looking for by mapping
:digraph.edgeover the output of:digraph.edges, but that’s a lot of round-trips to ETS to get what could have been one call to:ets.selecthttps://github.com/erlang/otp/blob/e78684732252a5b2b33de90adaf8f7ff80eb5a3c/lib/stdlib/src/digraph.erl#L307-L334
Also Liked
bjorng
Alternatively, you could specify you our own edge names when creating the edges. As long as there is only a single edge in each direction between each pair of vertices, the following should work:
stevensonmt
So that’s brilliant. I’m curious why that’s not the default behavior of
add_edge/3though? Implicitly naming an edge with{from, to}has to be more intuitive than whatever[:"$e" | N]is meant to convey.I also think it’s difficult to understand that this is possible from the docs for
add_edge/5because theedge()type is not documented. It’s also confusing to have edge “names” differ from edge “labels” and not document the “names” anywhere.jhogberg
The default edge names aren’t meant to convey anything: not giving them a name implies that you don’t care what they’re called.
The funny-looking names were most likely chosen because they’re more compact in memory and are unlikely to clash with user-named edges.
Last Post!
bjorng
I don’t know the original motivation for that feature, but one algorithm that needs it is Karger’s algorithm.