WIP: BipartiteGraph and Hopcroft-Karp algorithm in C++

[Upabjojr]

This is not supposed to be merged. These are algorithms needed for the commutative matcher of MatchPy. We will need these algorithms to port RUBI into C++.

Class BipartiteGraph was translated from its Python implementation at MatchPy

The Hopcroft Karp algorithm is my implementation, which solves the issue of relying on the GPL'd Python library (dependency of MatchPy).

• add license of MatchPy

[Upabjojr]

TItem is either TLeft or TRight. We could have typedef variant<TLeft, TRight> TItem, but this is probably only supported in C++17. As an alternative, two separate fields could be used. This latter alternative would probably some quantity of code to be reviewed.

[certik]

Try to use the formatting that our clang-format configuration enforces. The biggest one is to use 4 spaces, instead of tabs.

[certik]

@isuruf this is interesting. It looks like @Upabjojr applied the patch from our bot, but then the bot complained again. In particular, the bot first suggested the change:

-//(Generic[TLeft, TRight, TEdgeValue], MutableMapping[Tuple[TLeft, TRight], TEdgeValue])
+//(Generic[TLeft, TRight, TEdgeValue], MutableMapping[Tuple[TLeft, TRight],
+//TEdgeValue])

and after @Upabjojr applied it, our bot now suggests this one instead:

--- a/matchpygen/bipartite.h
+++ b/matchpygen/bipartite.h
@@ -22,7 +22,7 @@ const int RIGHT = 1;
 typedef map<tuple<int, int>, tuple<int, int>> Matching;
 
 //(Generic[TLeft, TRight, TEdgeValue], MutableMapping[Tuple[TLeft, TRight],
-//TEdgeValue])
+// TEdgeValue])
 /*
  * A bipartite graph representation.
  */

So the question is why didn't the bot suggest the correct (final) change in the first place?

[isuruf]

@Upabjojr, thanks for your work on this. I have two questions on the design decisions.

1. Do we need a TEdgeValue value? It seems unneeded.
2. The graph keeps left and right nodes, with an int to denote left or right. Why not use two graphs, one for left and one for right?

[Upabjojr]

Do we need a TEdgeValue value? It seems unneeded.

It's more generic, you can generalize the class usages to more types.

I am opening PRs to SymEngine, but that's only a temporary measure. We may decide to put the code in a separate project.

The graph keeps left and right nodes, with an int to denote left or right. Why not use two graphs, one for left and one for right?

I suppose you mean the _graph field, as the graph is only one. Right now, I am just translating the code written in Python in MatchPy. The usage of two separate class variables is an issue in MatchPy.

See HPAC/matchpy#43

[Upabjojr]

Added Takeaki Uno's algorithm. New code has not yet been tested.