New algorithm can dramatically streamline solutions to the ‘max flow’ problem
web.mit.edu
web.mit.edu
TL;DR: what's the fastest way to transport a large amount of data over a mesh of many small pipes
As someone who knows little about this problem or the laws of physics, I wonder if it could be solved using physics -- set up a series of physical pipes, pump water from A to B, measure the flow at each point? If that would work, how complicated would the mesh need to be that solving it with physics is faster than brute-force computation?
(The new problem is dealing with fluid dynamics.)
Water-based computation has already been done of course: http://en.wikipedia.org/wiki/MONIAC_Computer
http://www.americanscientist.org/issues/feature/the-soap-fil...
FWIW, as someone who designs massively parallel/distributed algorithms and went to school for chemical engineering, the conceptual model I use to design the aggregate behavior of complex networks are complex continuous flow chemical processes. All of the back pressure, flow overhead, reaction rates, equilibria, etc constructs are directly analogous to moving bits and doing computation in complex, distributed, heterogeneous computing systems. I think it is particularly effective for reasoning about distributed systems because chemical processes have no real concept of a global clock or shared state but still robustly and efficiently produce the desired output. It teaches you to reason about constructing optimal and robust global behaviors from subprocesses that only have local visibility and no explicit coordination between processes.
This is roughly in line with your intuition.
a much faster variant - this is a big deal!
Nobody uses brute-force computation to solve max-flow. The problem lies in P.
I cant wait to see the C99 code for that! (maybe I should try that myself)
The key bit however, is that the SDD solver as above, has really nice asymptotics for sparse matrices.
theres a few fancy algorithms that need to be engineered along the way, and theres also the question about how the constant factors work out in practice!
http://math.mit.edu/~kelner/publications.html
http://math.mit.edu/~kelner/Publications/Docs/1304.2338v2.pd...
Also, are there a class of algorithms where the current practical state of the art differs greatly from the theoretical or how would I go about finding out the answer to this question? Much obliged.
I kind of thought a lot of these routing problems were worked out or known not to be work-out-able. Just shows what I know :/ * sigh
However, that said, there are all kinds of interesting max flow problems, so hopefully it pans out in practice. Heck, even some profile based compiler optimizations can be formulated as max-flow problems.
EDIT: For an example, let's say the current best algorithm for some problem takes O(N^2), with a small constant (let's say 100 * N^2 operations). Then someone comes up with a O(N^1.9), but with a larger constant (let's say it takes 1,000,000 * N^1.9). The newer algorithm will practically be slower for any reasonably-sized input you can throw at it, even though it's a major theoretical breakthrough.
And "these papers" often do care about running time and will say whether it is possible to implement the algorithm efficiently, if you're lucky they'll even have done an implementation and you can see at what dataset sizes they are faster in practice.
And even if it were slower in practice, research like this is very useful, because it helps gives other researchers inspiration, ever since someone thought of looking at these problems like electrical flow in 2010, there have been ever faster approximations for it, while others will find ways to implement the algorithm efficiently, just in case a naive implementation of the offered algorithm isn't efficient enough.
Dismissing such research without having found any actual extreme inefficiencies in the proposed algorithm is not an attitude suited to anyone who wants to see progress.
And finally, the actual speed increase in the past decades hasn't been from O(N^2) to O(N^1.9) but from O(VE^2) to O(VE), which obviously does have a real impact, and even with a non-realistic 10000 times bigger constant it would still be far faster in any graph with more 10000 edges. And graphs with billions of edges aren't unusual anymore.
> Dismissing such research without having found any actual extreme inefficiencies in the proposed algorithm is not an attitude suited to anyone who wants to see progress.
I never dismissed this research or said it's not useful; on the contrary, it's very interesting. I was just arguing against the usefulness of benchmarking results for such algorithms, when the main improvement is the lower complexity.
EDIT:
> And finally, the actual speed increase in the past decades hasn't been from O(N^2) to O(N^1.9) but from O(VE^2) to O(VE), which obviously does have a real impact, and even with a non-realistic 10000 times bigger constant it would still be far faster in any graph with more 10000 edges. And graphs with billions of edges aren't unusual anymore.
One concrete example I had in mind is Strassen's algorithm, which reduces matrix multiplication from O(N^3) to O(N^2.8) or O(N^log 7). It doesn't seem to be worth it to use Strassen over the simple algorithm for relatively small matrices.
There are other examples of algorithms and data structures that offer an O(N log log N) time, where the previous algorithm needed O(N log N) to solve the same problem. You need a very large data set to justify using the former, especially if the latter are much simpler to implement.
> As you are talking about reasonably sized input, your constant examples should also be reasonable. 10000 times difference in the constant is not reasonable. You wouldn't even get that from going from all data in the level 1 cache to random memory access with 10 times more instructions.
10000 was just an example, I guess it was unrealistic. In practice, I think an 100x slowdown from an algorithm that has bad cache behavior makes some sense. [1] says that an L3 cache hit has a latency of 1-300 cycles, as opposed to a L1 hit that is only 4 cycles. That's almost an 100x difference, so theoretically a cache-friendly algorithm can be that much faster (and that's just the difference between L3 and L1, main memory takes even longer to access).
1 - http://stackoverflow.com/questions/4087280/approximate-cost-...
Of course it does, if you actually want the algorithm to be used in the real world.
"The main selling point of a better algorithm (and the main reason users would use it) is usually improved time complexity, not actual running time. "
I'm not sure where you get this. I have literally never seen anyone pick an algorithm based whose only benefit is "improved time complexity" when "actual running time" is worse for the majority of real world cases.
In particular, there are plenty of algorithms with "improved time complexity" but higher constant factors, and they don't get used.
As a concrete example: Most computations of dominators in compilers use theoretically worse (n log n instead of inverse ackerman) but practically better algorithms.
Also, you can't possible know when data is large enough to warrant it if nobody has taken the time to benchmark it.
The actual implementation is uninteresting and will always vary according to domain and optimization, but the intuition lesson is always a valid tool that we now have. And in hindsight this was a really obvious solution, carouse one should try all the routes and identify the bottlenecks.
Food for thought, single cpu core vs GPGPU.
I admire solution presented here however just saying.
Here's a nice little introduction I found with some reductions on the first couple slides: http://www.cs.princeton.edu/courses/archive/spr04/cos226/lec...
I just finished my algorithms undergrad class last semester; one of the questions on the final was 'you are a terrorist looking to cut off supplies to your enemy, which 3 nodes must you destroy to cut off the supply network?' And there was a complicated graph with probably 10 nodes and twice as many edges (very difficult to brute force in the allotted time), and we had to find the min-cut which would severe the flow. Some really cool problems reduce to max-flow.
Edit: I clicked the link, he used them exact slides. That set of slides comes up a lot, they're great.