-
Notifications
You must be signed in to change notification settings - Fork 140
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
Conversation
* 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]>
Pull Request Test Coverage Report for Build 2265763085
💛 - Coveralls |
""" | ||
super().__init__(graph=graph) | ||
self._subsets_num = k | ||
self._colors = colors if colors and len(colors) >= k else None |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 thecolors
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Co-authored-by: Claudia Zendejas-Morales <[email protected]>
0c62355
to
63ba6b1
Compare
|
||
References: | ||
[1]: Z. Tabi et al., | ||
"Quantum Optimization for the Graph Coloring Problem with Space-Efficient Embedding" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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))) |
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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).
@clausia Do you have any updates? If not, we will close this PR. |
@t-imamichi Hi, thanks for asking, I think it's best to close this PR and open another one when the update is ready |
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