Adding function to detect whether problem is infeasible or an optimal…

[tkralphs]

… solution is found

[mkoeppe]

While at it, perhaps it would be a good idea to fix the typo "isRelaxationAbondoned" and document what this problem status means?

[mkoeppe]

Thanks, Ted, together with cvxpy/cvxpy#1707, this fixes the testcase added in cvxpy/cvxpy#1705

[tkralphs]

@mkoeppe Apparently, I can't add you as a reviewer unless you are a member of the COIN-OR organization. Do you want to be added? Is this ready to go?

[mkoeppe]

This fixes the reported problem, but I am not sure if the fix is complete. It seems that the result 'solution' can now be produced in two ways: (1) On self.CppSelf.isProvenOptimal(), (2) From self.CppSelf.secondaryStatus().

Also the misspelling "abondoned" is still used in the result - or this part of the stable API?

[tkralphs]

OK, fixed that remaining typo and clarified what the status actually means. The way the statuses work in Cbc is a bit weird and the documentation in the header file is actually a bit misleading. What status zero actually means is that the search completed. But the result could still either be that a solution was found and proven optimal or that the problem was proven infeasible. That's why you have to then separately check which is those two actually occurred with the isProven* functions. So I think we should be good now.

[mkoeppe]

OK, am I understanding correctly that "search completed" is never actually returned by CyCbcModel.status?

[mkoeppe]

Also not sure if you had a chance to look at cvxpy/cvxpy@d390389 - am I mapping this correctly?

[tkralphs]

OK, am I understanding correctly that "search completed" is never actually returned by CyCbcModel.status?

Yes, that is true because it is a kind of useless status that encompasses both the feasible and infeasible cases. The reason it is listed there is because it is a status that exists internal to Cbc itself, but whenever we have that status, then it is guaranteed that either isProvenInfeasible() or isProvenOptimal() will be true and we need to use those functions to distinguish those two cases. So in the end, that status cannot actually be returned by CyCbcModel.status, but we have it to preserve the maping to Cbc's internal list of statuses. It's a bit messy. Perhaps this is something to be cleaned up in the refactoring of Cbc, if that ever gets finished.

[mkoeppe]

Another bug in the file:

problemStatus =  ['search completed', 'relaxation infeasible',
         'stopped on gap', 'stopped on nodes', 'stopped on time',
         'stopped on user event', 'stopped on solutions'
         'linear relaxation unbounded', 'unset']

misses a comma after 'stopped on solutions'

[tkralphs]

Good catch!

[mkoeppe]

This works well now.

[rsemenoff]

I assumed Cbc is multi-threaded, therefore the status should include "still computing"? But that goes beyond refactoring as I understand that term On Tuesday, March 15, 2022, 03:05:17 PM PDT, Ted Ralphs ***@***.***> wrote: OK, am I understanding correctly that "search completed" is never actually returned by CyCbcModel.status? Yes, that is true because it is a kind of useless status that encompasses both the feasible and infeasible cases. The reason it is listed there is because it is a status that exists internal to Cbc itself, but whenever we have that status, then it is guaranteed that either isProvenInfeasible() or isProvenOptimal() will be true and we need to use those functions to distinguish those two cases. So in the end, that status cannot actually be returned by CyCbcModel.status, but we have it to preserve the maaping to Cbc's internal list of statuses. It's a bit messy. Perhaps this is something to be cleaned up in the refactoring of Cbc, if that ever gets finished. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rsemenoff]

I wish that the true status of this project  (and the underlying Cbc) were more truthfully reported. I don't want to abuse volunteers, and I chose coin-or understanding that it was a funded project. What other known bugs are being covered up? Mixed-integer doesn't work and Im in the process of transitioning to CPLEX community edition...fingers crossed On Tuesday, March 15, 2022, 03:05:17 PM PDT, Ted Ralphs ***@***.***> wrote: OK, am I understanding correctly that "search completed" is never actually returned by CyCbcModel.status? Yes, that is true because it is a kind of useless status that encompasses both the feasible and infeasible cases. The reason it is listed there is because it is a status that exists internal to Cbc itself, but whenever we have that status, then it is guaranteed that either isProvenInfeasible() or isProvenOptimal() will be true and we need to use those functions to distinguish those two cases. So in the end, that status cannot actually be returned by CyCbcModel.status, but we have it to preserve the maaping to Cbc's internal list of statuses. It's a bit messy. Perhaps this is something to be cleaned up in the refactoring of Cbc, if that ever gets finished. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rsemenoff]

You should probably make it clear in the docs that this is only intended for python primitives. Although, what is the point of using python aside for the existence of major codebases like Pandas, Numpy, Scipy ... etc etc etc.  On Tuesday, March 15, 2022, 03:05:17 PM PDT, Ted Ralphs ***@***.***> wrote: OK, am I understanding correctly that "search completed" is never actually returned by CyCbcModel.status? Yes, that is true because it is a kind of useless status that encompasses both the feasible and infeasible cases. The reason it is listed there is because it is a status that exists internal to Cbc itself, but whenever we have that status, then it is guaranteed that either isProvenInfeasible() or isProvenOptimal() will be true and we need to use those functions to distinguish those two cases. So in the end, that status cannot actually be returned by CyCbcModel.status, but we have it to preserve the maaping to Cbc's internal list of statuses. It's a bit messy. Perhaps this is something to be cleaned up in the refactoring of Cbc, if that ever gets finished. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tkralphs]

You should probably make it clear in the docs that this is only intended for python primitives. Although, what is the point of using python aside for the existence of major codebases like Pandas, Numpy, Scipy ... etc etc etc.

@rsemenoff I really don't know what this means, but PRs are welcome. I am not the author of this package and I just try to maintain it as a side project because it seems to get a lot of use in the community. I have limited bandwidth and it would be great if the people who find it useful could pitch in. Updates to documentation are one easy way to contribute.

[tkralphs]

I wish that the true status of this project (and the underlying Cbc) were more truthfully reported. I don't want to abuse volunteers, and I chose coin-or understanding that it was a funded project.

@rsemenoff Where did you get the idea that COIN-OR is a funded project? COIN-OR has never had any substantial funding and that is certainly not hidden. I'm pleading for help with this project and Cbc every chance I get. Please read this and this and here, where it is stated "This has been moving slowly due to a lack of developer bandwidth," as well as numerous comments in issues and PRs. Cbc and CyLP are both currently being maintained by just a few volunteer maintainers. If you are happy with CPLEX, that's great and probably a better fit for you. And if you "don't want to abuse volunteers"... well, then just don't.

What other known bugs are being covered up?

Huh?

[rsemenoff]

That's right, and also CyLP itself advertises a long list of presumably-funded organizations as purported users. Who probably downloaded it for evaluation and abandoned soon after... On Thursday, March 17, 2022, 09:25:00 PM PDT, Ted Ralphs ***@***.***> wrote: I wish that the true status of this project (and the underlying Cbc) were more truthfully reported. I don't want to abuse volunteers, and I chose coin-or understanding that it was a funded project. Where did you get the idea that COIN-OR is a funded project? COIN-OR has never had any substantial funding and that is certainly not hidden. I'm pleading for help with this project and Cbc every chance I get. Please read this and this and here, where it is stated "This has been moving slowly due to a lack of developer bandwidth," as well as numerous comments in issues and PRs. Cbc and CyLP are both currently being maintained by just a few volunteer maintainers. If you are happy with CPLEX, that's great and probably a better fit for you. And if you "don't want to abuse volunteers"... well, then just don't. What other known bugs are being covered up? Huh? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***>

[rsemenoff]

I guess you have forgotten that I originally reported incorrect solver status, and you said you couldn't duplicate the issue, and then deleted my report of the issue because I said the status could be inferred by checking the solution vector against the constraints. On Thursday, March 17, 2022, 09:25:00 PM PDT, Ted Ralphs ***@***.***> wrote: I wish that the true status of this project (and the underlying Cbc) were more truthfully reported. I don't want to abuse volunteers, and I chose coin-or understanding that it was a funded project. Where did you get the idea that COIN-OR is a funded project? COIN-OR has never had any substantial funding and that is certainly not hidden. I'm pleading for help with this project and Cbc every chance I get. Please read this and this and here, where it is stated "This has been moving slowly due to a lack of developer bandwidth," as well as numerous comments in issues and PRs. Cbc and CyLP are both currently being maintained by just a few volunteer maintainers. If you are happy with CPLEX, that's great and probably a better fit for you. And if you "don't want to abuse volunteers"... well, then just don't. What other known bugs are being covered up? Huh? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***>

[rsemenoff]

I think there is some hiding going on within this one email from you.  Apparently you are a employed by a university and that job supports your living expenses while you develop free software. I wish it really was free software, but time was invested and wasted and I don't consider my time to be free to throw around at countless toy projects by bored staff at institutions. On Thursday, March 17, 2022, 09:25:00 PM PDT, Ted Ralphs ***@***.***> wrote: I wish that the true status of this project (and the underlying Cbc) were more truthfully reported. I don't want to abuse volunteers, and I chose coin-or understanding that it was a funded project. Where did you get the idea that COIN-OR is a funded project? COIN-OR has never had any substantial funding and that is certainly not hidden. I'm pleading for help with this project and Cbc every chance I get. Please read this and this and here, where it is stated "This has been moving slowly due to a lack of developer bandwidth," as well as numerous comments in issues and PRs. Cbc and CyLP are both currently being maintained by just a few volunteer maintainers. If you are happy with CPLEX, that's great and probably a better fit for you. And if you "don't want to abuse volunteers"... well, then just don't. What other known bugs are being covered up? Huh? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***>

[mkoeppe]

@tkralphs Don't feed the troll. You may find https://docs.github.com/en/communities/maintaining-your-safety-on-github/blocking-a-user-from-your-organization helpful

[rsemenoff]

Matthias Kooppe, another tenured university researcher: I would have been happier had I been blocked from this project over a year ago. But without a user base, its harder to get funding for projects is it not ? On Friday, March 18, 2022, 01:34:14 PM PDT, Matthias Köppe ***@***.***> wrote: @tkralphs Don't feed the troll. You may find https://docs.github.com/en/communities/maintaining-your-safety-on-github/blocking-a-user-from-your-organization helpful — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tkralphs]

@tkralphs Don't feed the troll. You may find https://docs.github.com/en/communities/maintaining-your-safety-on-github/blocking-a-user-from-your-organization helpful

Believe it or not, @rsemenoff has been an active and upstanding member of the CyLP community up until now. I have had a number of respectful and even productive conversations with them. For the time being, I'll give them the benefit of the doubt and hope they return to their senses after a good night's sleep. But thanks for pointing out that it's possible to ban people. That could come in handy.

[tkralphs]

I guess I will merge this PR now.