Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the Max-k-Cut application #299

Closed
wants to merge 29 commits into from

Conversation

clausia
Copy link

@clausia clausia commented Dec 13, 2021

Summary

Adding the Max-k-Cut to the application section

Details and comments

Max-k-Cut: Given an undirected graph, find a partition of nodes into at most k subsets such that the total weight of the edges between the k subsets is maximized. To solve this problem, the space-efficient quantum optimization representation (or encoding) for the graph coloring problem proposed in [1] is used.

This work has been done in collaboration between Claudia Zendejas-Morales (@clausia) and Vyron Vasileiadis (@fedonman). This contribution was done under QIntern 2021 (https://qworld.net/qintern-2021/) organized by QWorld, under the supervision of Adam Glos (@adamglos92) and Zoltan Zimboras (@zimboras). We would like to thank Kareem H. El-Safty (@kareem1925) for bringing up the idea of implementing space-efficient Max-k-Cut on qiskit.


[1]: Z. Tabi et al., "Quantum Optimization for the Graph Coloring Problem with Space-Efficient Embedding," 2020 IEEE International Conference on Quantum Computing and Engineering (QCE), 2020, pp. 56-62, doi: 10.1109/QCE49297.2020.00018.


Closes #255

* Add new Maxkcut class in qiskit_optimization/applications/max_k_cut.py

* Add tests for new Maxkcut class in test/applications/test_max_k_cut.py

* Add reference to Maxkcut class in qiskit_optimization/applications/__init__.py file

* Mention Maxkcut application in docs/tutorials/09_application_classes.ipynb

* Add necessary words in .pylintdict

* Add release notes regarding new Maxkcut class in releasenotes/notes/add-max-k-cut-app-7e451a5993171175.yaml

Co-authored-by: fedonman <[email protected]>
@coveralls
Copy link

coveralls commented Dec 14, 2021

Pull Request Test Coverage Report for Build 2265763085

  • 79 of 90 (87.78%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.02%) to 91.222%

Changes Missing Coverage Covered Lines Changed/Added Lines %
qiskit_optimization/applications/max_k_cut.py 78 89 87.64%
Totals Coverage Status
Change from base Build 2263161952: -0.02%
Covered Lines: 4292
Relevant Lines: 4705

💛 - Coveralls

"""
super().__init__(graph=graph)
self._subsets_num = k
self._colors = colors if colors and len(colors) >= k else None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For colors I see that more are allowed to be defined and presumably ignored; however if colors were given but less than k then they are discarded. In looking further, from what can see, these are just used if/when the user the draws the result.

I am wondering whether it might be better to move this off the constructor and just say have a method call something like set_draw_colors that takes the same thing and stores it for the rendering. That makes this feel less like part of the problem definition - at least to me. I would have said pass them on draw but then this is implementing logic defined in the base class and it does not seem to support customizing the rendering in this way.

In terms of the colors I think it should define what the string and int formats are - if its simply matplot color format then I think that can be stated perhaps with a link to matplot colot doc that has the info plus perhaps an example in the code to help people.

Also I wonder since this is a set of colors should they be passed in as a set so that it contains unique items - otherwise a user can specify the same color again. In regards of the behavior or more or less colors given than k maybe you prefer the less severe mechanism of discarding all or part of them depending on size. I think at least the code should emit a warning to alert the user - ideally they should be passing in k colors right not some other sized set. If this is a separate method just to set draw colors then maybe allowing only None (to reset to internal default) or a k sized set and raising a ValueError if the size if not equal to k might be more acceptable?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your comments, they have already been addressed:

  • The importance of including the definition of colors in the constructor is that this implementation is based on the "Graph Coloring Problem", but I understand your concern, we can have the solution of the max-k-cut problem without the need to draw the resulting graph. To change (or add) the colors you have the methods set/get (colors, called like that for the same reason, that we are thinking about the "Graph Coloring Problem").
    So, I have removed the colors parameter from the constructor, (before it was optional), I have already done this update.

  • As for the documentation, certainly including an example is much better for people who use this class, that update is ready, please review.

  • Regarding that the user can specify a repeated color, it seems to me that we should allow this type of flexibility, that this decision is up to the user, finally if it was not his/her intention, she/he will be able to see the result when he requests the drawing of the graph (the user will see fewer colors than 'k').

  • Now it is being validated that the size of the color list is equal to the k parameter, and if it is not, the ValueError is thrown indicating that the colors have not been assigned because they are not the correct amount.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@woodsp-ibm, what do you think of the changes?


n = self._graph.number_of_nodes()

# k colors chosen (randomly or from cm.rainbow), or from given color list
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as doing things randomly there exists an random generator in algorithm_globals in Terra that we created to have a common generator that algorithms and applications would use so that a user could create reproducible results by seeding it. Using that, instead of whats done here, would allow a user to seed it and have the same colored drawing each time if they prefer - of course they could pass in their own colors too, but I think using the common generator is preferable.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now algorithm_globals is used

@CLAassistant
Copy link

CLAassistant commented Jan 9, 2022

CLA assistant check
All committers have signed the CLA.


References:
[1]: Z. Tabi et al.,
"Quantum Optimization for the Graph Coloring Problem with Space-Efficient Embedding"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paper addresses a graph coloring problem and does not mention max-k-cut problem.
Could you refer an appropriate paper or page?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @t-imamichi, graph colouring problem is a decision variant of max-k-cut. Graph coloring problem is about checking if there "exists colouring of the nodes which make every edge connecting nodes with a different colour." Contrary, Max-K-Cut is about finding the colouring for which the number of such edges is maximized. You could say that graph colouring to max-K-Cut shows similar relation as SAT to MAX-SAT. For this reason, and the fact max cut is already used in the package we decided to choose max-k-cut name

Copy link
Collaborator

@t-imamichi t-imamichi Feb 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as the paper mentions only coloring problem, I don't think it's an appropriate citation of max-k-cut. It would confuse users. Why not rename the class "k-coloring problem" as the paper addresses?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moreover, there are many papers directly addressing max-k-cut problem. Why do you need to refer that paper (Tabi et al.) for max-k-cut class?

Copy link

@adamglos92 adamglos92 Feb 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The notion of feasibility changes. For Max-Cut every solution is feasible, for graph colouring only those with all edges connecting different nodes are feasible. This is obviously correct but inconsistent with max-cut used in the qiskit-optimization.
Since this is for optimization purposes mostly we found Max-K-Cut more accurate. But we can also move it to k-graph-coloring
We are not aware of older papers that propose the given formulation. If there is one, we're open to replacing the reference.

Copy link
Collaborator

@t-imamichi t-imamichi Feb 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mentioned

if there "exists colouring of the nodes which make every edge connecting nodes with a different colour."

But, coloring does not take care of edge weights. So, I don't think the optimal solution of coloring does not corresponds to the optimal solution to max-k-cut problem.

You must make a mixed integer programming model of max-k-cut. Here is the definition of k-cut value (though this page addresses minimization)
https://en.wikipedia.org/wiki/Minimum_k-cut

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may perhaps try to use an solution of coloring problem as a heuristic solution of max-k-cut problem?
If so, I ask you to make a proper mixed integer programming model of max-k-cut problem.
The model of application classes should be exact. Otherwise, even if we apply CPLEX or Gurobi to the model, we may not be able to obtain the optimal solution.

n = self._graph.number_of_nodes()
k = self._subsets_num
x = {(v, i): mdl.binary_var(name=f"x_{v}_{i}") for v in range(n) for i in range(k)}
first_penalty = mdl.sum_squares((1 - mdl.sum(x[v, i] for i in range(k)) for v in range(n)))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you make a model with a standard formulation of the problem? Please do not penalize constraints by yourself.
In the application classes, we make a model with a standard formulation. The conversion to QUBO will be done within algorithm classes.

x = {(v, i): mdl.binary_var(name=f"x_{v}_{i}") for v in range(n) for i in range(k)}
first_penalty = mdl.sum_squares((1 - mdl.sum(x[v, i] for i in range(k)) for v in range(n)))
second_penalty = mdl.sum(
mdl.sum(self._graph.edges[v, w]["weight"] * x[v, i] * x[w, i] for i in range(k))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this takes sum of edges whose end nodes are same color (i). Is it a correct k-cut value?
I think k-cut value is the sum of edges whose end nodes have different colors.
Anyways, could you refer an appropriate paper or page and make a model (obj func + constraints).

@manoelmarques manoelmarques removed the request for review from pbark June 29, 2022 18:26
@HuangJunye HuangJunye added the Commmunity PR PRs from contributors that are not 'members' of the Qiskit organization label Jun 30, 2022
@t-imamichi
Copy link
Collaborator

t-imamichi commented Aug 21, 2023

@clausia Do you have any updates? If not, we will close this PR.

@clausia
Copy link
Author

clausia commented Aug 21, 2023

@t-imamichi Hi, thanks for asking, I think it's best to close this PR and open another one when the update is ready

@t-imamichi t-imamichi closed this Aug 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Commmunity PR PRs from contributors that are not 'members' of the Qiskit organization
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Max-k-cut application
9 participants