A few known warts in the draft to remove.

1. Soooo many +2 s >_<
2. Circulation breaks the FlowNetwork encapsulation (this has led to bugs).
3. Use of maps to store capacity/preflow can probably be cleaned up to make things more efficient.

Might be cheaper to avoid maps to store capacity/preflows for something more cache-coherent.

Hello again!

Am I right that there is no option to change a sink dynamically, and if I want to calculate max flow in the same graph between different nodes - I have to recreate it each time?

Actually I think the most convenient api for that would be ability to just pass any two node ids to the Outflow function 🤔

Hey, I think it is worth documenting somewhere (maybe both in a source code and in a repo description) what algorithms do you use for solving these problems and what are their complexity.

Thanks for the project!

The circulation formulation may need to be tweaked to inject flow to nodes with negative node demands.

Thinking again, I believe the node demands also need to be connected to the source / sink of the circulation network.

Now that we have an adjacency list, it should be used to speed up iterations wherever possible.

Hello!

I was toying with visualgo.net to create some test cases, and I found this example which per visualgo should have maxflow of 28 from node 0 to 7, and your library calculates it as 29:

8 15
0 1 10 
0 2 5 
0 3 15 
1 2 4 
1 4 9 
1 5 15 
2 3 4 
2 5 8 
3 6 16 
4 5 15 
4 7 10 
5 6 15 
5 7 10 
6 2 6 
6 7 10

This text can be pasted in Edit graph -> Input graph, in the lower left corner. Note that you should choose 0-based indexing there.
Also, be aware that graph editing is quite buggy there, what I mean is that visualgo will often complain that the 0 node is not the leftmost one, and 7 node is not a rightmost one. Although it is drawn the graph itself. Just repeat pressing Input graph -> paste -> Submit few times, until it will draw them the way it wants.

And then from the same corner you can start one of the three algorithms. All three give 28.