I have an instance which could be very efficiently solved by old version of Z3(version 2.18). It return SAT in a few seconds.
However, when I try it on the current version of Z3(version 4.3.1). It does not return any result after 10 minutes.
Here are some details about the experiment. Could anybody give some advice?
there are 4000 Bool variables and 200 Int variables
all the constraint are in propositional logic with comparison between integers like a < b
platform: open suse linux 12.3#thinkpad T400s
Z3 v2.18 was downloaded as a linux binary last year (I cannot find the link now)
Z3 v4.3.1 was downloaded as source code, and I compile it on my laptop by using the default setting
There are about 50,000 lines in the smt file, so I can not post it here. I would be happy to send the file by email if anybody are interested.
Thanks.
Z3 is a portfolio of solvers. The default configuration changes from version to version.
Progress is never monotonic. That is, a new version may solve more problems, but may be slower and fail in some problems.
Remark: the author has sent his benchmark by email to the Z3 authors.
In the “work-in-progress” branch, I managed to reproduce the Z3 2.19 performance by using
(set-option :smt.auto-config false)
Here are instructions on how to download the “work-in-progress” branch.
To get the same behavior, we also have to replace
(check-sat)
with
(check-sat-using smt)
BTW, in the official release, we have to use
(set-option :auto-config false)
instead of
(set-option :smt.auto-config false)
Related
I am having trouble using emmeans to evaluate mean (or weighted mean) of all the predictions. For example, a mixed model:
library(emmeans)
library(lme4)
m1 <- lmer(mpg ~ 1 + wt + (1|cyl),data=mtcars)
Fixed effects "wt" is successful:
emmeans(m1,specs="wt")
wt emmean SE df lower.CL upper.CL
3.22 20.2 1.71 1.83 12.1 28.3
However, to calculate the mean of predictions, the following previously worked (~ 12 months ago), but now fails:
emmeans(m1,specs="1")
NOTE: Results may be misleading due to involvement in interactions
Error in `[[<-.data.frame`(`*tmp*`, ".wgt.", value = 1) :
replacement has 1 row, data has 0
The same error occurs for simple linear models. Many thanks for any help.
I thought I was using the current version of emmeans (1.4.8) when I had the troubles described in the question. However, I may actually have been using emmeans 1.4.6 (please see comment by Russ Lenth below). I reverted back to emmeans v1.4.3 and the code worked. I then updated to the current version of emmeans (1.4.8) and the code continued to work. Most likely the cause was my use of emmeans 1.4.6, which had a known bug. Please see this github entry for more information.
I have been looking into a development issue that requires the use of pseudorandom number generation to allow the same set of random numbers to be generated for a given seed.
I have currently been looking at using long random(void) and void srandom(unsigned seed) for this (man page), and currently these are generating the same set of random numbers in a Mac app, an iOS app and an iOS app (64-bit) which is what I was hoping. The iOS tests were only in the simulator so I don't know whether this will affect the result.
My main concerns is that this algorithm could change at some point, making the applications we're developing effectively useless with old data. What are the chances of these algorithms changing / being different on a future device?
I'd say it's extremely likely they will change as the sequence is not guaranteed by any standard.
Why not use your own random number sequence? Even a simple linear congruential generator satisfies most statistical properties of randomness. Here is the formula for such a generator:
next_number = (a * current_number + b) % c
with
a = 1103515245
b = 12345
c = 4294967296
These values of a, b, c give you good statistical properties and are quite well known for building quick and dirty generators.
I don't have the slightest idea about the answer to the question you ask.
If a related question is "How can I be absolutely sure to have the same pseudo-random sequences generated in 10 years time ?", the answer to this question is : don't rely on an external library, write the code explicitly.
Bathsheba proposed this generator. You can google for "pseudo random generator algorithm". Here is a list of algorithms listed on wikipedia.
In fact, srandom did change since Mac OS X 10.7, according to this blog post. However, this was due
to the way srandom was implemented: it tried to access an uninitialized local variable, which
is undefined behavior in C. According to the post, the new compiler used since Mac
OS X 10.7 optimized out the uninitialized memory access, changing its behavior in subtle
ways.
I saw in a previous post from last August that Z3 did not support optimizations.
However it also stated that the developers are planning to add such support.
I could not find anything in the source to suggest this has happened.
Can anyone tell me if my assumption that there is no support is correct or was it added but I somehow missed it?
Thanks,
Omer
If your optimization has an integer valued objective function, one approach that works reasonably well is to run a binary search for the optimal value. Suppose you're solving the set of constraints C(x,y,z), maximizing the objective function f(x,y,z).
Find an arbitrary solution (x0, y0, z0) to C(x,y,z).
Compute f0 = f(x0, y0, z0). This will be your first lower bound.
As long as you don't know any upper-bound on the objective value, try to solve the constraints C(x,y,z) ∧ f(x,y,z) > 2 * L, where L is your best lower bound (initially, f0, then whatever you found that was better).
Once you have both an upper and a lower bound, apply binary search: solve C(x,y,z) ∧ 2 * f(x,y,z) > (U - L). If the formula is satisfiable, you can compute a new lower bound using the model. If it is unsatisfiable, (U - L) / 2 is a new upper-bound.
Step 3. will not terminate if your problem does not admit a maximum, so you may want to bound it if you are not sure it does.
You should of course use push and pop to solve the succession of problems incrementally. You'll additionally need the ability to extract models for intermediate steps and to evaluate f on them.
We have used this approach in our work on Kaplan with reasonable success.
Z3 currently does not support optimization. This is on the TODO list, but it has not been implemented yet. The following slide decks describe the approach that will be used in Z3:
Exact nonlinear optimization on demand
Computation in Real Closed Infinitesimal and Transcendental Extensions of the Rationals
The library for computing with infinitesimals has already been implemented, and is available in the unstable (work-in-progress) branch, and online at rise4fun.
currently I am using Z3 with Python.
I want to create an assertion-stack, where I can push a level and pop it later.
It should work exactly like any other "stack" with push- and pop-operations.
Therefore the SMTLIB2-standard defines two functions "push(n)" and "pop(n)" with optional numbers n. In my case n would always be 1.
But there seems to be some strange behaviour in Z3.
Why does following code result in "index out of bounds"?
s = Solver()
s.push() # expected: one new level on the stack, reality: emtpy stack
s.pop(1) # expected: stack is empty, reality: exception (index out of bounds)
If I add an assertions, Z3 works as expected.
s = Solver()
s.push()
s.add(True) # now there is one level on the stack,
s.pop(1) # pop is successful
Even this works correct:
s = Solver()
s.add(True)
s.push() # now there is one level on the stack,
s.pop(1) # pop is successful
The problem is, that I do not know, how many levels and how many assertions are created in my program. It is possible, that there is no assertion at all and only one level. Then the program would crash (or catch the exception). A workaround would be adding some simple formula like "True" always as a first step, but this seems ugly.
Is this a bug in Z3 or is this behaviour correct?
This bug has been fixed in the unstable (working-in-progress) branch.
It will be available in the next official release. In the meantime, here are some instructions on how to compile the unstable branch. The fix is also available in the nightly builds available at codeplex.
I am getting strange statistics results when run Z3 3.1 with -st command option. If you press Ctrl-C, Z3 reports total_time < time. Otherwise, if you wait until Z3 finishes: total_time > time.
What does "total-time" and "time" measure?
Is it a bug(minor though)(the difference described above)?
Thanks!
This is a bug in Z3 for Linux (versions 3.0 and 3.1). The bug does not affect the Windows version. The fix will be available in the next release (Z3 3.2). The timer used to track time is incorrect.
BTW, total-time measures the total execution time, and time only the time consumed by the last check-sat command. So, we must have that total-time >= time.
Remark: this answer has been updated using the feedback provided by Swen Jacobs.