-
-
Notifications
You must be signed in to change notification settings - Fork 120
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
[問題案]Matching on Bipartite Graph(bipartitematching) #37
Comments
との報告がきた ランダムだけだと弱いよね…(トホホ) |
https://judge.yosupo.jp/submission/3463 いろいろミスってるのに通った |
最悪ケースがよくわからなかったが、https://codeforces.com/blog/entry/58048 ここに情報がまとまっていそう |
テストケース追加済っぽいので、 close |
Would it be possible to increase the limits to the same sizes as the bipartite ones? (V <= 10e5, E <= 2e5?). The current fastest runtimes are all 1ms, and the theoretical best running times of general graph matchings seem to be the same as the bipartite case? |
Basically, we don't change the constraints once the problem is published. However, we may add a hard version of a problem if necessary.
Many solutions solve:
Consequently, it seems hard to solve general matching within the same constraints. |
General matching also has some m\sqrt{n} time algorithms that seem implementable: https://arxiv.org/abs/2012.03582, https://dl.acm.org/doi/pdf/10.1145/115234.115366 Agree that it's a much harder problem though. Not clear if such variants will ever show up on CP.... I was just looking for a place where such implementations can be benchmarked. |
Thank you. |
My (likely false) impression from the bipartite case is that 'just' augmenting paths with some randomized tie breaking does fine, so I feel if it's a 5s limit, running a slower code for 5 minutes be more than sufficient to generate data. There are all sorts of generators from http://archive.dimacs.rutgers.edu/pub/netflow/instances/matching/ as well. So I should be able to put together and maintain a data set. |
I said about the implementation of the solution. |
I think https://judge.yosupo.jp/submission/51989 is a linear memory solution, so it should just work for 10^5 edges. My guess is constructing data to make this (plus some greedy initializations) is already a major challenge. I have heard of people with m^{1.5} implementations (e.g. https://tmt514.github.io/ has written papers on this). Let me ask around ... |
No description provided.
The text was updated successfully, but these errors were encountered: