I am working on a Linear Programming Formulation where I require some variables to take values from a predefined set. I was pointed out to use the CBC Lotsize Variable Type (https://github.com/coin-or/Cbc/discussions/516#discussioncomment-3007885). However the CBC C++ libraries use MPS format to be fed into them. I am not finding any way to create MPS file of my formulation. Please suggest the way forward...
FYI: Another similar request to Gurobi is pending: https://support.gurobi.com/hc/en-us/community/posts/9160893511185-Requesting-a-new-type-of-variable-introduction
Related
I'm using TF-Agents library for reinforcement learning,
and I would like to take into account that, for a given state,
some actions are invalid.
How can this be implemented?
Should I define a "observation_and_action_constraint_splitter" function when
creating the DqnAgent?
If yes: do you know any tutorial on this?
Yes you need to define the function, pass it to the agent and also appropriately change the environment output so that the function can work with it. I am not aware on any tutorials on this, however you can look at this repo I have been working on.
Note that it is very messy and a lot of the files in there actually are not being used and the docstrings are terrible and often wrong (I forked this and didn't bother to sort everything out). However it is definetly working correctly. The parts that are relevant to your question are:
rl_env.py in the HanabiEnv.__init__ where the _observation_spec is defined as a dictionary of ArraySpecs (here). You can ignore game_obs, hand_obs and knowledge_obs which are used to run the environment verbosely, they are not fed to the agent.
rl_env.py in the HanabiEnv._reset at line 110 gives an idea of how the timestep observations are constructed and returned from the environment. legal_moves are passed through a np.logical_not since my specific environment marks legal_moves with 0 and illegal ones with -inf; whilst TF-Agents expects a 1/True for a legal move. My vector when cast to bool would therefore result in the exact opposite of what it should be for TF-agents.
These observations will then be fed to the observation_and_action_constraint_splitter in utility.py (here) where a tuple containing the observations and the action constraints is returned. Note that game_obs, hand_obs and knowledge_obs are implicitly thrown away (and not fed to the agent as previosuly mentioned.
Finally this observation_and_action_constraint_splitter is fed to the agent in utility.py in the create_agent function at line 198 for example.
I'm trying to write an SWI-Prolog predicate that applies numbervars/3 to a term's anonymous variables but preserves the user-supplied names of its non-anonymous variables. I eventually plan on adding some kind of hook to term_expansion (or something like that).
Example of desired output:
?- TestList=[X,Y,Z,_,_].
> TestList=[X,Y,Z,A,B].
This answer to the question Converting Terms to Atoms preserving variable names in YAP prolog shows how to use read_term to obtain as atoms the names of the variables used in a term. This list (in the form [X='X',Y='Y',...]) does not contain the anonymous variables, unlike the variable list obtained by term_variables, making isolation of the anonymous variables fairly straightforward.
However, the usefulness of this great feature is somewhat limited if it can only be applied to terms read directly from the terminal. I noticed that all of the examples in the answer involve direct user input of the term. Is it possible to get (as atoms) the variable names for terms that are not obtained through direct user input? That is, is there some way to 'write' a term (preserving variable names) to some invisible stream and then 'read' it as if it were input from the terminal?
Alternatively... Perhaps this is more of a LaTeX-ish line of thinking, but is there some way to "wrap" variables inside single quotes (thereby atom-ifying them) before Prolog expands/tries to unify them as variables, with the end result that they're treated as atoms that start with uppercase letters rather than as variables?
You can use the ISO core standard variable_names/1 read and write option. Here is some example code, that replaces anonymous variables in a variable name mapping:
% replace_anon(+Map, +Map, -Map)
replace_anon([_=V|M], S, ['_'=V|N]) :- member(_=W, S), W==V, !,
replace_anon(M, S, N).
replace_anon([A=V|M], S, [A=V|N]) :-
replace_anon(M, S, N).
replace_anon([], _, []).
variable_names/1 is ISO core standard. It was always a read option. It then became a write option as well. See also: https://www.complang.tuwien.ac.at/ulrich/iso-prolog/WDCor3
Here is an example run:
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.25)
?- read_term(X,[variable_names(M),singletons(S)]),
replace_anon(M,S,N),
write_term(X,[variable_names(N)]).
|: p(X,Y,X).
p(X,_,X)
To use the old numbervars/3 is not recommended, since its not compatible with attribute variables. You cannot use it for example in the presence of CLP(FD).
Is it possible to get (as atoms) the variable names for terms that are not obtained through direct user input?
if you want to get variable names from source files you should read them from there.
The easiest way to do so using term expansion.
Solution:
read_term_from_atom(+Atom, -Term, +Options)
Use read_term/3 to read the next term from Atom.
Atom is either an atom or a string object.
It is not required for Atom to end with a full-stop.
Use Atom as input to read_term/2 using the option variable_names and return the read term in Term and the variable bindings in variable_names(Bindings).
Bindings is a list of Name = Var couples, thus providing access to the actual variable names. See also read_term/2.
If Atom has no valid syntax, a syntax_error exception is raised.
write_term( Term ) :-
numbervars(Term, 0, End),
write_canonical(Term), nl.
I was wondering if anyone who has used the Optimization Library in Dymola has been able to utilize the RealtimeOptimization function without having explicit plant constitutive equations to input into the criteriaFunction? Specifically, I am trying to use some of my model's states as the criteria function, but when I input y[1] := mymodel.state; with or without quotes around the state, Dymola rejects the function. Any thoughts would be very helpful. Thank you.
It is not possible to have access to model variables inside a function. You have to provide the values of the variables through the inputs to the function. The task RealtimeOptimization is aimed to be called during the simulation of a Modelica model. The criteria function has the defined inputs nTuners, nCriteria, tuners[nTuners]. You can add additional input variables, see the Example Optimization.Tasks.RealtimeOptimization.Examples.Example02.RunSampled and the record UserData in the function Optimization.Tasks.RealtimeOptimization.Examples.Example02.criteriaFunc02. By these additional variables you could transfer some state variables into the critiera function.
Maybe we can assist you, if you provide more information about your setting. I am the main developer of the Optimization library in Dymola.
You could try adding outputs (Modelica.Blocks.Interfaces.RealOutputs) to the top level of the model and then linking these to the states by using Modelica.Blocks.Sources.RealExpression blocks.
Then when using the optimisation function goto the criteria page and use the Select button and select these outputs to add them as criteria.
Howcome some languages like PHP and Python use dynamic name resolution?
The only time I've ever thought of using it is to do something like this Python code, to save me from having to explicitly parameters to format:
"{a} {b} {c} {d}".format(**locals())
but it doesn't really take much work to just be explicit (and is a bit less error-prone):
"{a} {b} {c} {d}".format(a=a, b=b, c=c, d=d)
And for setting/getting locals in the same scope, I don't see why anyone would ever use that instead of a map.
Without dynamic name resolution, typos are caught, and you can automatically rename variables without breaking your program (unless something can still read the names of the variables). With dynamic name resolution, you get something that saves you from typing a line? Am I missing something?
Python documentation says they might remove it in the future. Is it more of a historical thing? What's an actual good use case for dynamic name resolution?
Most dynamically typed languages simply don't have a choice. For an expression like x.y you can't look up y statically, since what fields are available depends on the type of x which is only available at runtime.
There are ways around this (such as type inference or JIT), but since the base language has to have dynamic name lookup, most such languages make it into a feature (see e.g. the power of Lua tables).
I introduced myself to the GMP library for high precision arithmetic recently. It seems easy enough to use but in my first program I am running into practical problems. How are expressions to be evaluated. For instance, if I have "1+8*z^2" and z is a mpz_t "large integer" variable, how am I to quickly evaluate this? (I have larger expressions in the program that I am writing.) Currently, I am doing every single operation manually and storing the results in temporary variables like this for the "1+8*z^2" expression:
1) first do mpt_mul(z,z,z) to square z
2) then define an mpz_t variable called "eight" with the value 8.
3) multiply the result from step one by this 8 and store in temp variable.
4) define mpz_t variable called "one" with value 1.
5) add this to the result in step 3 to find final answer.
Is this what I am supposed to be doing? Or is there a better way? It would really help if there was a user's manual for GMP to get people started but there's only the reference manual.
GMP comes with a C++ class interface which provides a more straightforward way of expressing arithmetic expressions. This interface uses C++ operator overloading to allow you to write:
mpz_class z;
1 + 8 * z**2
This is, of course, assuming you're using C++. If you are using C only, you may need to use the C interface to GMP which does not provide operator overloading.
Turns out that there's an unsupported expression parser distributed with GMP in a "expr" subdirectory. It's not part of GMP proper and is subject to change but it is discussed in a README file in that directory. It isn't guaranteed to do the calculation in the fastest way possible, so buyer beware.
So the user must manually evaluate all expressions when using GMP unless they wish to use this library or make their own expression parser.