Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Feature request: directed acyclic graph implementation in common.graph
See original GitHub issueAs it turns out, since I originally posted #2411, the needs for my university project evolved a bit, as I realised I really needed a directed acyclic graph (DAG) rather than a tree.
I believe JGraphT provides an implementation of a DAG, but despite that I decided to settle on Guava 20-rc1 and common.graph recently (on one hand because I had licensing worries with JGraphT, and on the other hand because I think common.graph is currently a much cleaner alternative to both JGrapht and JUNG), so I would be excited to see DAG support in say (Graph|ValueGraph|Network)Builder, in a method like supportsCycles(boolean), so I don’t have to implement cycle-checking support myself anymore.
What does the Guava team think of this request?
Issue Analytics
- State:
- Created 7 years ago
- Reactions:5
- Comments:38 (22 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Glad to hear you like common.graph!
This is one thing we considered as an option on the *Builders, but is not in the current release because it requires either A) additional memory overhead (e.g. a UnionFind type data structure kept in sync with the graph) or B) a much slower addEdge() method (checking for a cycle on each add).
There is Graphs.hasCycle(), which if you called after every mutation is closer to the second solution.
That sounds fair enough to me. Thanks for taking the time to contribute to the earlier discussion @jrtom!