Some things that I think work well for SMT solvers:
1. Bounded model checking for source code.
2. Finding solutions to constraint problems.
3. Design rule checking for hardware layout and logic gates.
Recently, I built a simple scheduling system using Z3. My wife is a librarian supervisor, and she's been spending hours each week creating schedules by hand. But, with a little Z3, one can enumerate the constraints and let it find a viable example. If the example doesn't work, add more constraints until it does.
Can you give an example of the kinds of constraints that need to get tweaked?
And do you have to tweak them in Z3 each time?
Disclaimer: I know almost nothing about Z3. I'm just picturing you trying to convince her that something like datalog has a learning curve that she'll Totally Be Glad she Powered Through, and she'll Thank you Later for Talking he Into It :)
Numbers were such that you could only ever handle a fraction of the possible work. The throughout of a good allocation could be significantly higher than a naive one.
So you wanted to avoid to work with epsilon-delta in the reals
Question, do you use intuitionistic logic or classical logic?
If you use intuitionistic logic, why not model smooth infinitesimal analysis?
Is this trying to prove things about Python code, or is it a Python interface to Z3, or something else?
It is not trying to prove things about python code.
It is building facilities and theory libraries around the pre-existing z3 python interface in a manner that can be reasonably called an interactive theorem prover. Hopefully, eventually, with a lower barrier to entry (and probably lower expressivity ceiling) than pre-existing systems like Lean, Coq, Isabelle.
I am targeting applications close to my heart, like calculus, differential equations, dynamical systems, numerical calculations, software verification. It is a tall order. No promises.
I have had a decent number of times where if I was told "write this code in this Python DSL, and then you can do interactive theorem proofs just on that bit", I would be pretty satisfied, even if it meant really cutting down what kind of objects I could use in the process.
All of these seem to find solutions to user-provided constraint sets. They must be appropriate for different classes of problems, but it’s not obvious to me how that breaks out.
It’s, uh, been a long time since I last hand-rolled an optimization algorithm…
Prolog has some operational flavor to it. You can predict what it'll do. It can be used as "just" a programming language akin to python with fairly little logical/mathemtical content. Declarative Prolog as in constraint logic programming is in the realm of attacking similar logical problems to z3.
scipy.optimize is a grab bag of stuff. Some of it is pretty heuristic. It's all subject to floating point error, which is the devil we live with. The milp and lp solvers are relatives of how z3 handles linear inequality constraints. scipy.optimize doesn't treat logic at all really. It takes in mathematical multivariate functions and finds roots or minima.
Z3 is intended to be mathematically rigorous. It is less operational than prolog. On big combinatorial problems (SAT, bitvector problems), it is probably a superior tool. It does have an optimization interface, I haven't used it much.
