I am using VST and I frequently have to apply commutativity in mpreds.
For example, I want to transform a current goal A * B |-- X into B * A |-- X.
For the moment, I use to assert : H : A * B |-- B * A and then call sep_apply H
Do you know if there is any immediate tactic ?
Best
Related
I am having trouble understanding the difference between an equality and a local definition. For example, when reading the documentation about the set tactic:
remember term as ident
This behaves as set ( ident := term ) in * and
using a logical (Leibniz’s) equality instead of a local definition
Indeed,
set (ca := c + a) in *. e.g. generates ca := c + a : Z in the context, while
remember (c + a ) as ca. generates Heqca : ca = c + a in the context.
In case 2. I can make use of the generated hypothesis like rewrite Heqca., while in case 1., I cannot use rewrite ca.
What's the purpose of case 1. and how is it different from case 2. in terms of practical usage?
Also, if the difference between the two is fundamental, why is remember described as a variant of set in the documentation (8.5p1)?
You could think of set a := b + b in H as rewriting H to be:
(fun a => H[b+b/a]) (b+b)
or
let a := b + b in
H[b+b/a]
That is, it replaces all matched patterns b+b by a fresh variable a, which is then instantiated to the value of the pattern. In this regard, both H and the rewrited hypotheses remain equal by "conversion".
Indeed, remember is in a sense a variant of set, however its implications are very different. In this case, remember will introduce a new proof of equality eq_refl: b + b = b + b, then it will abstract away the left part. This is convenient for having enough freedom in pattern matching etc... This is remember in terms of more atomic tactics:
Lemma U b c : b + b = c + c.
Proof.
assert (b + b = b + b). reflexivity.
revert H.
generalize (b+b) at 1 3.
intros n H.
In addition to #ejgallego's answer.
Yes, you cannot rewrite a (local) definition, but you can unfold it:
set (ca := c + a) in *.
unfold ca.
As for the differences in their practical use -- they are quite different. For example, see this answer by #eponier. It relies on the remember tactic so that induction works as we'd like to. But, if we replace remember with set it fails:
Inductive good : nat -> Prop :=
| g1 : good 1
| g3 : forall n, good n -> good (n * 3)
| g5 : forall n, good n -> good (n + 5).
Require Import Omega.
The variant with remember works:
Goal ~ good 0.
remember 0 as n.
intro contra. induction contra; try omega.
apply IHcontra; omega.
Qed.
and the variant with set doesn't (because we didn't introduce any free variables to work with):
Goal ~ good 0.
set (n := 0). intro contra.
induction contra; try omega.
Fail apply IHcontra; omega.
Abort.
I was testing Coq rewrite tactics modulo associativity and commutativity (aac_tactics). The following example works for integer (Z), but generates an error when integers are replaced by rationals (Q).
Require Import ZArith.
Import Instances.Z.
Goal (forall x:Z, x + (-x) = 0)
-> forall a b c:Z, a + b + c + (-(c+a)) = b.
intros H ? ? ?.
aac_rewrite H.
When replacing Require Import ZArith. with Require Import QArith. etc., there is an error:
Error: Tactic failure: No matching occurence modulo AC found.
at aac_rewrite H.
There was a similar inconsistency issue between Z and Q, which turned out to be related to whether the Z/Q scope is open.
But I don't understand why aac rewrite didn't work here. What's the cause of the inconsistency, and how can one make it behave the same for Z and Q?
The AAC_tactics library needs theorems which express associativity, commutativity and so forth. Let's take Qplus_assoc which expresses the associativity law for the rational numbers.
Qplus_assoc
: forall x y z : Q, x + (y + z) == x + y + z
As you can see Qplus_assoc doesn't use =, it uses == to express the connection between the left-hand side and the right-hand side. Rationals are defined in the standard library as pairs of integers and positive numbers:
Record Q : Set := Qmake {Qnum : Z; Qden : positive}.
Since, e.g. 1/2 = 2/4, we need some other way of comparing the rationals for equality (other than = which is the notation for eq). For this reason the stdlib defines Qeq:
Definition Qeq (p q : Q) := (Qnum p * QDen q)%Z = (Qnum q * QDen p)%Z.
with notation
Infix "==" := Qeq (at level 70, no associativity) : Q_scope.
So, in case of rational numbers you might want to rewrite your example to something like this:
Require Import Coq.QArith.QArith.
Require Import AAC_tactics.AAC.
Require AAC_tactics.Instances.
Import AAC_tactics.Instances.Q.
Open Scope Q_scope.
Goal (forall x, x + (-x) == 0) ->
forall a b c, a + b + c + (-(c+a)) == b.
intros H ? ? ?.
aac_rewrite H.
Search (0 + ?x == ?x).
apply Qplus_0_l.
Qed.
I was following (incomplete) examples in Coq 8.5p1 's reference manual in chapter 11 about the mathematical/declarative proof language. In the example below for iterated equalities (~= and =~), I got a warning Insufficient Justification for rewriting 4 into 2+2, and eventually got an error saying:
No more subgoals, but there are non-instantiated existential
variables:
?Goal : [x : R H : x = 2 _eq0 : 4 = x * x
|- 2 + 2 = 4]
You can use Grab Existential Variables.
Example:
Goal forall x, x = 2 -> x + x = x * x.
Proof.
proof. Show.
let x:R.
assume H: (x = 2). Show.
have ( 4 = 4). Show.
~= (2*2). Show.
~= (x*x) by H. Show.
=~ (2+2). Show. (*Problem Here: Insufficient Justification*)
=~ H':(x + x) by H.
thus thesis by H'.
end proof.
Fail Qed.
I'm not familiar with the mathematical proof language in Coq and couldn't understand why this happens. Can someone help explain how to fix the error?
--EDIT--
#Vinz
I had these random imports before the example:
Require Import Reals.
Require Import Fourier.
Your proof would work for nat or Z, but it fails in case of R.
From the Coq Reference Manual (v8.5):
The purpose of a declarative proof language is to take the opposite approach where intermediate states are always given by the user, but the transitions of the system are automated as much as possible.
It looks like the automation fails for 4 = 2 + 2. I don't know what kind of automation uses the declarative proof engine, but, for instance, the auto tactic is not able to prove almost all simple equalities, like this one:
Open Scope R_scope.
Goal 2 + 2 = 4. auto. Fail Qed.
And as #ejgallego points out we can prove 2 * 2 = 4 using auto only by chance:
Open Scope R_scope.
Goal 2 * 2 = 4. auto. Qed.
(* `reflexivity.` would do here *)
However, the field tactic works like a charm. So one approach would be to suggest the declarative proof engine using the field tactic:
Require Import Coq.Reals.Reals.
Open Scope R_scope.
Unset Printing Notations. (* to better understand what we prove *)
Goal forall x, x = 2 -> x + x = x * x.
Proof.
proof.
let x : R.
assume H: (x = 2).
have (4 = 4).
~= (x*x) by H.
=~ (2+2) using field. (* we're using the `field` tactic here *)
=~ H':(x + x) by H.
thus thesis by H'.
end proof.
Qed.
The problem here is that Coq's standard reals are defined in an axiomatic way.
Thus, + : R -> R -> R and *, etc... are abstract operations, and will never compute. What does this mean? It means that Coq doesn't have a rule on what to do with +, contrary for instance to the nat case, where Coq knows that:
0 + n ~> 0
S n + m ~> S (n + m)
Thus, the only way to manipulate + for the real numbers it to manually apply the corresponding axioms that characterize the operator, see:
https://coq.inria.fr/library/Coq.Reals.Rdefinitions.html
https://coq.inria.fr/library/Coq.Reals.Raxioms.html
This is what field, omega, etc... do. Even 0 + 1 = 1 is not probable by computation.
Anton's example 2 + 2 = 4 works by chance. Actually, Coq has to parse the numeral 4 to a suitable representation using the real axioms, and it turns out that 4 is parsed as Rmult (Rplus R1 R1) (Rplus R1 R1) (to be more efficient), which is the same than the left side of the previous equality.
I'm having some troubles in Coq when trying to perform case analysis on the result of a function (which returns an inductive type). When using the usual tactics, like elim, induction, destroy, etc, the information gets lost.
I'll put an example:
We first have a function like so:
Definition f(n:nat): bool := (* definition *)
Now, imagine we are at this step in the proof of a specific theorem:
n: nat
H: f n = other_stuff
------
P (f n )
When I apply a tactic, like let's say, induction (f n), this happens:
Subgoal 1
n:nat
H: true = other_stuff
------
P true
Subgoal 2
n:nat
H: false = other_stuff
------
P false
However, what I want is something like this instead:
Subgoal 1
n:nat
H: true = other_stuff
H1: f n = true
------
P true
Subgoal 2
n:nat
H: false = other_stuff
H1: f n = false
------
P false
In the way it actually works, I lose information, specially I lose any information about f n. In the problems I work with, I need to use the information that f n = true or f n = false, to use with other hypothesis, etc.
Is there a way to do the 2nd option?
I tried using stuff like cut(f n = false \/ f n = true) but it becomes very tiresome, specially when I have several of these "special" inductions in a row. I want to know if there is something that basically works exactly like the cut above, but with fewer tactics/proofs
The issue is that you perform induction on a constructed term, not a single variable. Keeping the information in your case has been proved to be a very difficult problem.
The usual work-around is to abstract your constructed term using the remember tactic. I don't have the exact syntax in mind right now but you should try something like
remember (f n) as Fn. (* this introduces an equality HeqFn : Fn = f n *)
revert f n HeqFn. (* this is useful in many cases, but not mandatory *)
induction Fn; intros; subst in *.
Hope it helps,
V.
I would like to somehow limit what kind of inputs constructors are allowed to take in an inductive definition. Say I want to say define binary numbers as follows:
Inductive bin : Type :=
| O : bin
| D : bin -> bin
| S : bin -> bin.
The idea here is that D doubles up a nonzero number by adding a zero at the end and S takes a number with zero as the last digit and turns the last digit into a one. This means that the following are legal numbers:
S 0
D (S 0)
D (D (S 0))
while the following would not be:
S (S 0)
D 0
Is there a way to enforce such restrictions in an inductive definition in a clean way?
You could define what it means for a bin to be legal with a predicate, and then give a name to the subset of bins that obey that predicate. Then you write functions with Program Definition and Program Fixpoint instead of Definition and Fixpoint. For recursive functions you'll also need a measure to prove the arguments of your functions decrease in size since the functions are not structurally recursive anymore.
Require Import Coq.Program.Program.
Fixpoint Legal (b1 : bin) : Prop :=
match b1 with
| O => True
| D O => False
| D b2 => Legal b2
| S (S _) => False
| S b2 => Legal b2
end.
Definition lbin : Type := {b1 : bin | Legal b1}.
Fixpoint to_un (b1 : bin) : nat :=
match b1 with
| O => 0
| D b2 => to_un b2 + to_un b2
| S b2 => Coq.Init.Datatypes.S (to_un b2)
end.
Program Definition zer (b1 : lbin) := O.
Program Fixpoint succ (b1 : lbin) {measure (to_un b1)} : lbin :=
But this simply-typed approach would probably be easier.
This could be done with inductive-recursive definitions - but unfortunately Coq doesn't support those.
From an object-oriented programming perspective, O, D and S are subtypes of bin, and their constructor types are then definable without resorting to logical predicates, but Coq doesn't support object-oriented programming natively either.
However, Coq does have typeclasses. So what I might do is make bin a typeclass, and make each of the constructors a separate inductive type, each of which has an instance of the bin typeclass. I'm not sure what the method(s) of the typeclass would be though.