I was reading LaValle's backward value interation but, completely failed to understand the example 2.9, which is mentioned in the text, works.
Would someone be able to intuitively explain how backward value iteration works?
Related
I'm having trouble figuring out how to debug z3. Is there a way to see what the SMT engine is "trying" to make it easier to understand why it's failing to see a solution that seems obvious and where it's devoting it's time instead?
As an example in my particular circumstance, I'm working with a recursive function and setting z3 to find inputs where the function has a certain result. SMT was timing out, yadda yadda yadda, turns out the thing I was recursing on had a base case of 0, but if it ever went negative, it'd recurse forever. Z3 didn't know not to pick a negative number, so it'd get stuck. I figured that out by staring at the code, but if I had some output somewhere that said "trying i == -10, trying i == -11, etc" it'd be very obvious what was going wrong.
I'm continuing to have less obvious issues, and I suspect Z3 is still getting stuck in loops. How can I see the loop it's getting stuck in?
It is unfortunately very difficult to find out why exactly Z3 is running forever, but typical culprits are matching loops due to bad patterns (a quantifier instantiations yields new ground terms that trigger another instantiations, and so on) and non-linear arithmetic.
The Z3 axiom profiler, described in this paper can help with identifying problems due to too many quantifier instantiations.
I am using the python API of the Z3 solver to search for optimized schedules. It works pretty well apart from that it sometimes is very slow even for small graphs (sometimes its very quick though). The reason for that is probably that the constraints of my scheduling problem are quite complex.
I am trying to speed things up and stumbled on some articles about incremental solving.
As far I understood, you can use incremental solving to prune some of the search space by only applying parts of the constraints.
So my original code was looking like that:
for constraint in constraint_set:
self._opt_solver.add(constraint)
self._opt_solver.minimize(some_objective)
self._opt_solver.check()
model = self._opt_solver.mode()
I changed it now to the following:
for constraint in constraint_set:
self._opt_solver.push(constraint)
self._opt_solver.check()
self._opt_solver.minimize(some_objective)
self._opt_solver.check()
model = self._opt_solver.mode()
I basically substituted the "add" command by the "push" command and added a check() after each push.
So first of all: is my general approach correct?
Furthermore, I get an exception which I can't get rid of:
self._opt_solver.push(constraint) TypeError: push() takes 1 positional argument but 2 were given
Can anyone give me a hint, what I am doing wrong. Also is there maybe a z3py tutorial that explains (with some examples maybe) how to use incremental solving with the python api.
My last question is: Is that at all the right way of minimizing the execution time of the solver or is there a different/better way?
The function push doesn't take an argument. It creates a "backtracking" point that you can pop to later on. See here: http://z3prover.github.io/api/html/classz3py_1_1_solver.html#abc4ae989afee7ad164844640537107d9
So, it seems push isn't really what you want/need here at all. You should simply add your constraints one-by-one and call check. However, I very much doubt checking after each addition is going to speed anything up significantly. The optimizing solver (as opposed to the regular one), in particular, usually solves everything from scratch. (See the relevant discussion here: https://github.com/Z3Prover/z3/issues/1577)
Regarding incremental: The python API is automatically "incremental." Incremental simply means the ability to call the command check() multiple times, without the solver forgetting what it has seen before. (i.e., call check, assert more facts, call check again; the second check will take into account all the assertions from the very beginning.) You shouldn't make any assumptions regarding this will give you speed over calling check just once at the very end: It entirely depends on the heuristics and the decision procedures involved, which is dependent on the problem at hand.
I am facing a simple problem in Maxima: I want to calculate list of first derivatives of function / expression in various points. I know how to calculate list of "points" for normal expression:
float(makelist((x^2/sin(x-x/2),x,1,1000))
but when I run the expression through diff it changes expression to function and I don't know how to work with functions. I tried:
float(makelist(diff(x^2/sin(x-x/2)),x,1,1000))
which "zeroed" on me. Then I tried this:
float(makelist(''(diff(x^2)),x,1,1000))
which gives you right answer, but the result is not a number anymore. It's a list of something like:
[2.0 del(1.0), 4.0 del(2.0), 6.0 del(3.0), 8.0 del(4.0), ...
Would someone care to enlighten me about Maxima functions and numeric evaluation?
I know that this is a silly beginner's question, but I have never worked with Maxima before.
I think you want float(makelist(''(diff(x^2, x)),x,1,1000)) i.e. you need to write diff(expression, variable) instead of just diff(expression).
I am using =MODE(B1:F85) to get the MODE, how do I get which is the second most frequent value after 10?
Thanks
This should return the second most frequent value:
=ArrayFormula(MODE(IF((B1:F85=MODE(B1:F85)),"",B1:F85)))
As an aside, I think the fact you need to use "" in the second argument, rather than omitting the argument altogether, is (in my opinion) a low-grade bug, which I will report. Nevertheless, the above formula should still work even if the behaviour was changed accordingly.
I'm trying to make z3 (I'm using z3py) to simplify some formulas for me (so that I can have more or less human-readable output). Using ctx-solver-simplify tactic seemed a good choice for me since in a couple of passes it would produce nice compact formulas. But soon I've run into a situation when the output of ctx-solver-simplify does not seem to be equivalent to the original formula (it looks more like being satisfiability-equivalent or so). Also, it might be the case that I'm not dealing with tactics correctly.
Here's what I was trying to do: http://rise4fun.com/Z3Py/g5sX. So, I construct a formula Set2 (everything before the definition of Set2 is just a setup needed to define it) which has a particular satisfying assignment. After applying ctx-solver-simplify, I get a single formula (as a goal) for which this assignment is not satisfying. So what am I dong wrong?
Am I wrong assuming that ctx-solver-simplify would produce an equivalent formula?
Am I handling the tactics and their output in the wrong way?
Anything else?
Thanks.
I have been looking into this, but have so far been unable to reproduce the bug directly
with our current branch. A bug in the context simplifier was fixed a little while ago, and it could
be manifesting itself with the online version of Z3.
There are still a few things I can do to double check if we can reproduce the bug
and I will update this post with what I find.