Live data from Hacker News

Maximum Flow and Minimum-Cost Flow in Almost-Linear Time

arxiv.org

11–20 of 44 posts

Re: Maximum Flow and Minimum-Cost Flow in Almost-Linear Time

#13
post #2

Would love a tldr if anyone has a link.

Richard Peng (and coauthors) has a lot of great work (such as this: https://epubs.siam.org/doi/abs/10.1137/110845914 as well as his more recent paper with Sidford).

But agree with the other commenters that implementing this is often quite difficult and there might be extremely high constants involved.

Re: Maximum Flow and Minimum-Cost Flow in Almost-Linear Time

#15

Coming to a software engineering interview near you!

It's so amusing how interviewers pose questions that took PhD students years to invent the answers to. Just say you want me to memorize some algorithms and their time+space complexities, and regurgitate them on command.

Re: Maximum Flow and Minimum-Cost Flow in Almost-Linear Time

#16
post #15

Coming to a software engineering interview near you!

It's so amusing how interviewers pose questions that took PhD students years to invent the answers to. Just say you want me to memorize some algorithms and their time+space complexities, and regurgitate them on command.

is that not what they basically say? Most large companies will tell you to read a an algorithms book and give hints as to what questions they ask.

Re: Maximum Flow and Minimum-Cost Flow in Almost-Linear Time

#17
post #10
post #2

Would love a tldr if anyone has a link.

I've just skimmed, but the paper is quite unkind about its internal details (which is very typical for mathies, hahaha). I think the algorithm is non-exact. Say, Theorem 1.1 explicitly mentions probability: > There is an algorithm that, on a graph G = (V, E) with m edges, vertex demands, edge costs, and upper/lower edge capacities, all integral and bounded by U in absolute value, computes an exact min-cost flow in m1…

The algorithm is exact, but probabilistic. That means that if you repeat it enough times, you're almost certain to find a solution.

Here's an example of how that works. Suppose you have a polynomial f(x) of degree n. I'll show a probabilistic algorithm that'll find an integer k such that f(k) != 0 with probability p >= 1/2.

Here goes: pick a random non-negative integer k below 2n. That's it, that's our answer.

What's the probability that f(k) != 0? Well, a polynomial of degree n can have at most n zeros, so at most n out of 2n non-negative integers below 2n are bad answers, so the probability of k being bad (i.e. f(k) = 0) is = 1/2.

Now, probability 1/2 might seem pretty bad, we're, after all, rather likely to get a wrong answer. There's a simple way to deal with it, though: just repeat the algorithm as many times as you need. For example, if we repeat the algorithm 10 times, the probability of getting 10 wrong answers is 1/2^10 = 1/1024, rather small indeed. After 100 times, the probability of getting wrong answer is negligible.

Of course, it's easy to come up with an exact, non-probabilistic algorithm for the problem above. However, my probabilistic algorithm is O(1), while it's easy enough to prove that no constant time, non-probabilistic algorithm for the problem exists. I imagine that the situation is similar with the algorithm in the paper above: I'd wager that we get almost-linear time thanks to probabilistic nature.

Oh, and I was also cheating above somewhat: sure, my algorithm is O(1), but verifying that the answer is actually correct is O(n), so I cannot get an arbitrary small probability with my algorithm using the method above in constant time. The situation is, however, better in the context of maximum flow problem, because one can, in fact, check whether a flow is maximum in linear time, so that we can amplify the probability of getting a correct answer without losing the linear complexity.

Re: Maximum Flow and Minimum-Cost Flow in Almost-Linear Time

#18
post #15

Coming to a software engineering interview near you!

It's so amusing how interviewers pose questions that took PhD students years to invent the answers to. Just say you want me to memorize some algorithms and their time+space complexities, and regurgitate them on command.

That’s not what I’m looking for in those kinds of interviews. For example, one of my fav problems has a Range Sum Query tree idea as the main solution. But I’m more than happy to lead any developer to the solution, they come away happy with new knowledge, I see how they respond to hints and think on a new problem. Always fun and heard a lot of direct thanks for that from interviewees.
Post reply on HN