Are there any good solutions for updating the rhs of a constraint? Preferably I would like to do something like:
import pyscipopt as scp
Mod=scp.Model()
x=Mod.addVar(ub=3,name="x")
y=Mod.addVar(ub=4,name="y")
c=Mod.addCons(x+y<=2,"C1")
Mod.setObjective(0.5*x+0.3*y, "maximize")
Mod.optimize()
print(Mod.getObjVal())
c.updateRHS(4) # This function does not exist..
Mod.optimize()
print(Mod.getObjVal())
This is fixed in the latest version of PySCIPOpt (see https://github.com/SCIP-Interfaces/PySCIPOpt/pull/70)
The methods are called chgLhs() and chgRhs(). Keep in mind that they are only going to work for linear and quadratic constraints for now.
Related
When I make a contour plot with Python, I have been using a set_aspect function. Because this allows me to avoid image/contour-lines distortion caused by changing both axis.
: for example, ax1.set_aspect('equal', 'box-forced')
But, I just found that the option 'box-forced' is not valid in Python3.
So my question is, is there any alternative of the 'box-forced' option in Python3? I want exactly the same effect as the ax1.set_aspect('equal', 'box-forced') in Python2.
Thanks!
I just found that there is a function plt.axis('scaled').
It seems that this does what I wanted in a recent version (3.7) of Python3.
You can try this one from the official documentation that I found in as my first recommended page:
https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.set_aspect.html
I'm not sure what you're trying to accomplish here exactly, but you could try the following:
ax1.set_aspect(aspect='equal', adjustable='box')
You could also check the following link which is for the set_adjustable method:
https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.set_anchor.html#matplotlib.axes.Axes.set_anchor
Hope this helps. Good luck!
I recently updated Astropy to the new 3.2(.1) version. Suddenly a lot of AstropyDeprecationWarnings started to appear.
I used to deal with them in this way:
from astropy.utils.exceptions import AstropyDeprecationWarning
import warnings
warnings.simplefilter('ignore', category = AstropyDeprecationWarning)
However, with this new Astropy version, the filter is basically ignored and the warnings keep showing.
It is not a vital problem, the code works of course, but I would like to get rid of them because they make the output more difficult to read. Is there a way to solve this problem? Am I doing something wrong?
Thanks!
Edit:
The two warnings that I see more often are:
WARNING: AstropyDeprecationWarning: astropy.extern.six will be removed in 4.0, use the six module directly if it is still needed [astropy.extern.six]
WARNING: AstropyDeprecationWarning: Composition of model classes will be removed in 4.0 (but composition of model instances is not affected) [astropy.modeling.core]
I think the second warning arises because of this line of code where I am combining a Gaussian model + a background:
model = models.Gaussian1D(amplitude = flux.max()*0.9, mean = 0., stddev = size) \
+ models.Const1D(amplitude = flux.min()*0.9)
I have no idea where the first warning comes from. I do not explicitly import astropy.extern.six (I actually do not know what it is) so it might be something related to the second warning or from a third party code.
Edit v2:
I investigated this a little bit more since the combination of models is not responsible for the warnings as I first thought. Apparently the astropy.extern.six warning arises from:
from astroquery.ned import Ned
While the composition of model classes warning arises from:
import photutils as ph
I'm reading introduction into PyTorch and a bit confused by the Tensor.requires_grad_(...) function. Why would one would prefer it instead of just using the setter: Tensor.requires_grad = ... ? Setter syntax seems to be more clean and readable. Why to introduce this strange function with this funny underscore suffix?
I am trying to use Sympy to simplify some trigonometry. I realize that Sympy has a mature set of tools for dealing with this, so it seems like I must be missing something. However, I have spent a lot of time searching and can't seem to find exactly what I am looking for.
Question: How do you expand a simple trig function into its complex components?
MWE:
x = Symbol('x',real=True)
# The following works. Note that it expands cmplx functions into trig fncs
exp(I*x).expand(complex=True)
# Now try to go the other way
expand(sin(x)) #nope
expand_trig(sin(x)) #nope
expand(sin(x),complex=True) #nope
expand_complex(sin(x)) #nope
I also tried replace, rewrite, and xreplace, but didn't get anywhere.
I have some code that includes a menhir-based parser for a domain specific language (a logic). For the sake of my sanity while debugging, it would be great to be able to type instances of this language (formulas) directly in the toplevel like so:
# f = << P(x,y) & x!=y >>
Is campl4/5 my only option? If yes, I find the documentation rather intimidating. Is there an example/tutorial that is close-enough to my use case and that I could conceivably adapt? (For instance, syntax extensions that introduce new keywords do not seem relevant). Thanks!
If you're willing to call a function to do the parsing, you can use ocamlmktop to include your parser into the top level. Then you can install printers for your types using #install_printer. The sessions might look like this then:
# let x = parse ()
<< type your expression here >>
# x : type = <<formatted version>>
I have used specialed printers, and they definitely help a lot with complicated types. I've never gotten around to using ocamlmktop. I always just load in my code with #load and #use.
This is a lot easier than mastering camlp4/5 (IMHO). But maybe it's a bit too crude.
Yes, you can use camlp4 and it will work reasonably well (including in the toplevel), but no, it's not well-documented, and you will have to cope with that.
For an example that is close to your use-case, see the Lambda calculus quotation example of the Camlp4 wiki.
For the toplevel, it will work easily. You can dynamically load "camlp4o.cmo" then your syntactic extension in the toplevel, or use findlib which handles that: from the toplevel, #use "topfind";;, then #camlp4o;;, then #require "myfoo.syntax";; where myfoo.syntax is the name of the findlib package you've created to deploy your extension.