New feature: maximum matching of general graph

[EdgarAlenPoe]

The new pull request after the issues with #2530

Fixes #2403

[codecov]

Codecov Report

Attention: Patch coverage is 96.04520% with 7 lines in your changes are missing coverage. Please review.

Project coverage is 84.61%. Comparing base (8226110) to head (47dbabb).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2550      +/-   ##
===========================================
+ Coverage    84.58%   84.61%   +0.03%     
===========================================
  Files          376      376              
  Lines        60595    60772     +177     
  Branches     11850    11881      +31     
===========================================
+ Hits         51253    51423     +170     
- Misses        9342     9349       +7     

Files	Coverage Δ
src/misc/matching.c	95.48% <96.04%> (+0.26%)	⬆️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8226110...47dbabb. Read the comment docs.

[szhorvat]

@ntamas The interface here is based on the stub function that was accidentally left over in 0.10 (though not exposed). As I said in chat, I am not sure that using m[v] = u to represent the u-v match is a good idea. In fact, this representation is plainly insufficient for weighted multigraphs, as we need to distinguish between parallel edges.

We certainly need a way to return specific edge IDs.

We should discuss what representation is best to use, and change the interface before 1.0 is relesaed. This should probably stay an experimental function in 1.0 as well, so we have the opportunity to make changes in the future.

[ntamas]

Yes, one would need the edge IDs in weighted multigraphs -- but only in weighted multigraphs and not in weighted simple graphs or non-weighted multigraphs, where the matching vector is enough.

One option would be provide the edge IDs only in the result, and provide a helper function that converts the edge IDs to a matching vector if this is what the user ultimately needs. Another option would be to provide two output arguments: one for the matching vector (as we do it now) and one for the edges in the matching. I think that if we think about higher-level interfaces only, then providing the edge IDs is enough as the higher-level interface can easily wrap the edge IDs in a purpose-built object (like a Matching class) that provides easy access to the matching as well if the user wants that. When using igraph in C, the user would need to jump through an extra hoop to get the matching vector if we provide the edge IDs only. On the other hand, people working directly in C are probably not scared of the extra complexity.

All in all, I'm okay with changing the interface to provide the IDs of the edges in the matching only, as long as we also provide a helper function to convert it quickly to a matching vector.

[szhorvat]

Suggested change

	*
	*
	* \experimental
	*

Just so we don't forget.

[EdgarAlenPoe]

The algorithm itself uses the m[v] = u approach internally, and it's probably necessary.
This makes me kinda favor the two output arguments approach, as we already have the one.
However this isn't the most clean for the weighted multigraph case as there's an argument that becomes unnecessary.

I'm really fine with either, and will get started implementing it once we decided this.

[szhorvat]

We didn't forget this PR, just need to find the time to go over it. It's a non-trivial amount of work.

The m[v] = u approach is fine internally, but the interface can still be such that returning an edge set is possible.

Changing the interface is relatively easy. The first step of the review should be verifying correctness and performance.