Implemented methods concerning removability in a matching covered graph

[janmenjayap]

The objective of this issue is to implement the methods pertaining to removability in a matching covered graph.

More specifically, this PR aims to implement the following methods:

• is_removable_edge() | Check whether the edge is removable.
• is_removable_doubleton() | Check whether the pair of edges constitute a removable doubleton.
• is_removable_ear() | Check whether the ear is removable.
• is_removable_double_ear() | Check whether the pair of ears form a removable double ear.
• removable_edges() | Return a :class:~EdgesView of removable edges.
• removable_doubletons() | Return a list of removable doubletons.
• removable_ears() | Return a list of removable ears.
• removable_double_ears() | Return a list of removable double ears.

This PR shall address the methods related to removable edges, removable ears, removable doubletons and removable double ears of matching covered graphs.

Fixes #38216.
Note that this issue fixes a small part of the mentioned issue.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

This PR depends on the PR #38742.

cc: @dcoudert .

[github-actions]

Documentation preview for this PR (built with commit 0be2316; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[dcoudert]

I'm changing the status to needs work.

This branch is under development and it should not be tested each time you push a small commit like 9d1bd4e. Most of these tests should first be done in your local installation of sagemath and not in the cloud. This is a considerable waste of computing resources.

[janmenjayap]

I'm changing the status to needs work.

This branch is under development and it should not be tested each time you push a small commit like 9d1bd4e. Most of these tests should first be done in your local installation of sagemath and not in the cloud. This is a considerable waste of computing resources.

Hi,
I will take care of this from now onwards. I will push the commit provided there is reasonable enough changes that can be tested, after testing them out locally.

[janmenjayap]

Hi,
This requires finding an M-augmenting path (yes! I need to update that comment in line 2641) starting and ending with the vertices u and v.

Currently, there is no implementation in sage, that addresses this (as per my knowledge). In fact, the implementation of Edmond's algorithm has been done with the help from networkx.

This implementation will require defining some utility classes like Blossom and Flower, that might be helpful for Micali-Vazirani algorithm as well. So, for now, one possibility would be defining an auxiliary method (namely augment_matching in matching.py that takes a matching and two exposed vertices and returns a matching of higher weight/ cardinality by running a matching swap through the augmenting path joining the two exposed vertices, of course in a different PR).

Please let me know your suggestions in this context.
Thank you.

[dcoudert]

isn't it method M_alternating_even_mark in matching.py ?

[janmenjayap]

M_alternating_even_mark() just finds those vertices which satisfy an analogous condition of finding all vertices that are reachable from u through an M-alternating path, starting with an edge not in M ending with an edge in M.

Here, we are sure that from u to v there exists an M-augmenting path (starting and ending with edges not in M). But we want to augment that path with the current matching (aka we want to take the symmetric difference of the current matching and that path: essentially flipping the matched and unmatched edges throughout that path in order to get a matching whose cardinality is one more than the current matching thus giving us a perfect matching in G $-$ e).

The only difference here is to obtain the required path from u to v, as this requires blossom shrinking.

There is this local method, namely augmentMatching() in networkx.max_weight_matching() that is required in this case.

PS: I got to know this method networkx.max_weight_matching() while looking for how Edmond's algorithm has been implemented in matching() in matching.py.

[dcoudert]

I understand. I agree that adding method augment_matching (or any suitable name) to matching.py is needed here.

[dcoudert]

Setting back to needs work.

It it good to add examples, but I think you add way to much of them. Consider limiting to the most important to show the behavior of the method and test required functionality.