Graphs.jl
Graphs.jl copied to clipboard
JuliaGraphs
An optimized graphs package for the Julia programming language
The guilty lines of code: https://github.com/JuliaGraphs/Graphs.jl/blob/53cb58152a19ca62fa01439300948c30035dca6a/src/digraph/transitivity.jl#L105-L108 Is there a reason why: - the function dispatches on a concrete graph type - it doesn't support undirected graphs? First spotted by https://github.com/JuliaGraphs/SimpleWeightedGraphs.jl/issues/10
`random_configuration_model(3, [2, 0, 0])` never halt. This is because our implementation of the random configuration model does not allow self loops and multi-edges. In itself, it is already an oddity...
https://github.com/JuliaGraphs/Graphs.jl/blob/1a7594a448b0c8fe9251ac7e88fd1b5ab0989e87/src/core.jl#L1-L5 Could we have a documentation for `AbstractPathState` ? Currently, the total information in the doc about this type is almost zero, or at least I could not easily find...
See #278 with `condensation`
I read through the documentation for Graphs.jl and I understood that the provided implementations of `AbstractGraph` (_e.g_, `SimpleGraph`) assumed that the vertices were contiguous and started from 1 (_e.g._ 1,...
The Hopcroft-Karp algorithm computes a maximum-cardinality matching of a bipartite graph. This algorithm is very useful, and I would like to use it in some other projects. I'm opening this...
The LP-based algorithms of both packages are being migrated to GraphsOptim, but the combinatorial algorithms (with minimal dependencies) could and should probably go into the main library See also #108
It wouldn't be so hard to set up PythonCall in the test suite and test correctness of most algorithms against their Python counterpart
In the PRs done by @simonschoelly to test on generic graphs, he frequently ran into trouble because collections like `vertices(g)` or `neighbors(g, v)` were not indexable. This explains the appearance...
Metadata
Owner
Metadata
An optimized graphs package for the Julia programming language