-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move code from GraphsFlows and GraphsMatching to Graphs #191
Comments
@gdalle I have opened a PR for the migration of GraphsFlows.jl to the main package. The only algorithm remaining is |
I've accidentally tried to merge the wrong branch. I have created a new PR. |
@gdalle Should we port the code from BlossomV as well? The |
It would be really great to port the BlossomV dependency since it has an awful licence: in practice, the GraphsMatching.jl package only works as long as the BlossomV code is hosted at the original URL (which it stopped being at one point) |
Implementing BlossomV was part of a jsoc project in the past that did ultimately not succeed. The algorithm is not that trivial, and the paper omits some technical steps that have to be figured out - I had looked into implementing it myself in the past, but never found the time. It is doable though, for example the was implementation for JGraphT done for gsoc in the past. |
Would it make sense to migrate just the Hungarian algorithm from GraphsMatching into Graphs.jl? I would like to use this implementation, but am hesitant to depend on GraphsMatching due to the dependency on BlossomV. |
As a first step that would be good! Wanna give it a try? I can do my best to review it quickly. @thchr I didn't find that second PR you mentioned? Did you ever get around to it? |
I would be willing to give this a try. However, I just realized that GraphsMatching's Hungarian algorithm depends on Hungarian.jl. I am assuming that this is the kind of one-off dependency that Graphs.jl would like to avoid. |
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
The text was updated successfully, but these errors were encountered: