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
Say very loud that LP variables are non-negative by default #15482
Comments
Branch: u/ncohen/15482 |
Commit: |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:3
The changes and cleanups (thanks!) look good to me. Can you also put the warning in one additional place - the docstring for the class |
comment:4
What do you think ? I added a warning and removed some lines which (I believe) did not help much and make the doc easier to read. Nathann |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:6
Ok. Looks good to me now. Enough shouting. :) |
Reviewer: Punarbasu Purkayastha |
comment:7
Great and fast work. But... sorry, not loud enough. If you look at the LP tutorial, there is no indication of this (other than a parenthetical "for instance when you want some variables to be negative") - and that is where people will end with current SEO results. This doc does have it in the opening example, but even there it is not as visible as possible. I think that for positive review here, we really need to have a And we all know that students only look for worked examples in order to do their homework, so why should it be any different with working people in the mathematical sciences? :-) |
comment:8
You are right - but should there be a "warning" in a tutorial? I think it should be a usual statement. The MIP mentions it in the introductory part and then Nathann has already fixed it for the MILP part. Is there anywhere else in MIP that you have in mind? |
comment:9
Hmmmmmm... Right for the thematic tutorial, I am doing this right now. Right for the first example of the MIP module, though I did it in the first version of the patch I submitted to finally remove it, as adding a warning or actually a bold text more or less "broke" the flow of this explanation. Hmmm.. I'll give it another try and add a commit to this ticket. Nathann |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:12
I'm happy with the content of this as respects my earlier comment - thanks. I don't know what it looks like, and a little of the details have changed (what happened to |
comment:13
Oh, well I removed this "dim" thing and I should deprecate it anyway. I'll send a patch for that today. I wrote this "dim" thing when I had no idea that As per the lines, they should be 80 characters long if Emacs did its job Nathann |
comment:14
(just created #15489 for this Nathann |
comment:15
Ok. Looks good to me. One paragraph (line 135...) has 80-87 characters long lines. Not a big deal for me. I think your emacs setting has 85 chars not 80. You can update the ticket if you want with reflowed lines. |
Changed reviewer from Punarbasu Purkayastha to Punarbasu Purkayastha, Karl-Dieter Crisman |
comment:26
Sorryyyyyyy guys, there was a broken doctest in graph.py because of the change to MixedIntegerLinearProgra.solve which removed an old argument. SOoooooo this thing is waiting for a review again Nathann |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:29
What is up with the hundreds of failing doctests? |
comment:30
I knew something was weird. The doctests passed on my computer, and I was wondering if there was something new with the deprecation warnings, like they are "only shown once" in the first doctests of each file and never again. It all passed. I guess it was a bug and all functions need to be fixed, which seems natural. I am recompiling the commit over beta1 and I will check it again. Hoping that the doctests fail on my computer, this time Nathann |
comment:31
Oh. Well. All tests pass in both the graph/ and numerical/ folder Soooooooo where are your broken doctests, actually ? Nathann |
comment:32
(sorry about my previous comment by the way. I was thinking of a different patch) |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:35
Is this supposed to work on Sage-6.0? I get 70 doctests fails. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:37
70 fails ? Where ? I just rebased it on 6.2.beta1 (which should change nothing at all), and well...
Nathann |
comment:38
I got one doctest failure:
|
comment:39
Oh. I fixed it already somewhere else, I am pretty sure. Anyway, some later patch will conflict Anyway, fixed again ! Nathann |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:41
Looks good. This process took inordinately long just for documentation changes. :( |
comment:42
Thaaaaaaaaanks !!! I will now rebase #15489, its branch name is red for some reason Nathann |
comment:43
OK, confirm all tests passed, too. I'm slowly coming to grips with the system. |
Changed branch from u/ncohen/15482 to |
As the title says. It has been reported once again. We make this assumption because ALL lp solvers that we use make the same, but it does not mean everybody knows it
T_T
Nathann
CC: @kcrisman
Component: documentation
Author: Nathann Cohen
Branch/Commit:
9a7657b
Reviewer: Punarbasu Purkayastha, Karl-Dieter Crisman, Thierry Monteil
Issue created by migration from https://trac.sagemath.org/ticket/15482
The text was updated successfully, but these errors were encountered: