-
Notifications
You must be signed in to change notification settings - Fork 1
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
Review request #1
Comments
I and other JHU collaborators have worked on this problem for some time. there are various datasets in https://github.com/adalisan/SeededGraphMatch/tree/master/data that would be useful for testing. We also found the auction algorithm to be the harder-to-scale part of the SGM algorithm. |
@adalisan This implementation is based on work from Carey Priebe et al at Hopkins. Did you guys ever try using the auction algorithm for the assignment problem? The JHU implementations I'd seen used Hungarian/JV. |
Carey was my PhD advisor. I vaguely remember people considering an alternative matching algorithm or implementation, I am not sure if it was YiCao or JV or the auction algorithm . but if the only advantage is parallelizability of the auction algorithm and not lower computationally complexity, then we didn't consider the auction algorithm. Maybe try paging @jovo for clarification? Is there an easy-to-use implementation for the auction algo? |
Ah cool. I can't remember the complexity of auction vs JV off the top of my head -- but parallelizability + ability to be distributed is a nice property :) Not sure what the best implementation of the auction algorithm is out there. I have a reasonably concise one here: |
@adalisan Here's an easy-to-use implementation of the auction algorithm. Just wrote it now, so possibly some errors or inefficiencies, but seems to work reasonable well. https://github.com/bkj/numba_auction Comparing auction to JV is interesting -- relative runtimes seem to change a lot depending on the properties of the cost matrix. |
Older versions of scipy (which is what we call for LAP) were using Hungarian, since 1.4 they are using a modified JV from https://ieeexplore.ieee.org/document/7738348 From that paper,
I wonder if this is related to what you mean by runtimes depending on cost matrix a lot |
wikipedia suggests O(n^3) for hungarian and JV. complexity of the auction algorithm is more vague, but as you suggest it may be exploiting sparsity in the cost matrix. |
JV is n^2.x for sparse graphs. see "assignment problems" book for details.
…________________________________
From: Sancar Adali <[email protected]>
Sent: Thursday, June 4, 2020 1:10 AM
To: owensgroup/csgm <[email protected]>
Cc: jovo Vogelstein <[email protected]>; Mention <[email protected]>
Subject: Re: [owensgroup/csgm] Review request (#1)
wikipedia suggests O(n^3) for hungarian and JV. complexity of the auction algorithm is more vague, but as you suggest it may be exploiting sparsity in the cost matrix.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAKG4TSHAOVYVI5RR72V5TRU4UFPANCNFSM4F6KTW7A>.
|
This is nearly done, subject to some final testing on additional datasets to find edge cases.
@ctcyang has already looked at this and optimized some bits, but any feedback would be appreciated.
Depending on the dataset, the bottleneck should be SpMM or the auction algorithm. (I'm working on implementing/testing a CUB version of the auction algorithm that should make better use of parallelism, but that won't change a whole lot of code.)
The text was updated successfully, but these errors were encountered: