How can I convert nat to Q (Rational) in Coq?
I want to be able to write things like this:
Require Import Coq.QArith.QArith.
Open Scope Q_scope.
Definition a := 2/3.
When I try to do this, Coq tells me:
Error: The term "2" has type "nat" while it is expected to have type "Q".
You can write something like:
Definition a := Z.of_nat 2 # Pos.of_nat 3.
The # operator is just notation for the Qmake constructor of the Q type. That constructor takes elements of Z and positive as arguments, so you need the casts to be able to put nats in there.
If you're using literal number syntax, you can also use Z and positive directly:
Definition a := 2 # 3.
The difference is that this definition won't mention the convertions for nat; the numbers will already be in the right type, because Coq interprets the number notation as a Z and a positive directly.
I personally don't like the standard Coq rational number library very much, because it uses equivalence rather than Leibniz equality; that is, the elements of Q 1 # 1 and 2 # 2 are equivalent as rational numbers, but are not equal according to Coq's equality:
Goal (1 # 1 <> 2 # 2).
congruence.
Qed.
There's a feature called setoid rewrite that allows you to pretend that they are equal. It works by only allowing you to rewrite on functions where you proved to be compatible with the notion of equivalence on Q. However, there are still cases where it is harder to use than Leibniz equality.
You can also try the rat library of the Ssreflect and MathComp packages (see the documentation here). It has a definition of rationals that works with Leibniz equality, and it is more comprehensive than Coq's.
Related
I want to use this definition to assume that certain equalities on the members of set R hold:
Definition wiring: Prop
(globalHasVoltage -> (voltageOf voltageIn) = vcc)
/\
(globalHasGround -> (
(voltageOf control) = zero
/\
(voltageOf ground) = zero
)
)
.
It seems coq distinguishes between Prop and bool, what are the differences, and how may i solve that issue?
Also If this definition implies some other definition (per say lets call it toBeEvaluated) and assuming that conversion between bool and prop can be done could this
Definition toBeEvaluated: Prop := (voltageOf voltageIn) = vcc.
be proven using unwraps and tauto. (In particular will it work with functions which have exact definitions)
The difference between Prop and bool is that definitions in Prop might be undecidable, while definitions in bool can always be computed (unless you use axioms). Many number types have bool and Prop equality operators, but R doesn't because equality in R is in principle undecidable, so one can't write an equality function for R which results in a bool. Imagine e.g. the equality of different infinite series which sum up to pi - one can't design a general algorithm which decides if two series result in pi or not. Electronics uses functions like sin which rely on such infinite series.
A few options / thoughts:
R is not a very appropriate type for signal levels. E.g. voltage levels like GND or VCC are not mathematically equal everywhere. You could e.g. work with ranges in Q to express signal levels.
Another appropriate type might be floating point numbers, which are supported by Coq (meanwhile also natively). Have a look at the coq-flocq package. For floating point numbers equality is decidable, but they won't be able to represent a voltage like 1.8V exactly.
Another option is to have an inductive type which has a few well known signal levels (GND, VCC, ...) but also a constructor for arbitrary R (either classic or constructive). At least for the well known levels equality would be decidable then, but not for the arbitrary levels.
Even though = is not decidable in R, you can usually proof equality of R expressions, e.g. using the ring or field tactic. But you can't prove automatically that say sin(pi/4)=cos(pi/4). Well of cause one can automate this as well, but such automation always will have limits. But this means that your equalities always need to be proven with tactics and can't be just computed.
I have a type BoundedNat n, representing natural numbers smaller than n. My current implementation is as follows:
Definition BoundedNat n := {x : nat | x < n}.
Manipulating elements of type BoundedNat n is relatively heavyweight. I constantly need to wrap (using exist n ltac:(lia)) and unwrap (using proj1_sig) elements. How can I best piggyback off the underlying type's notations, equality, ordering, etc.?
Though you can definitely roll up your own implementation of bounded natural numbers, I strongly encourage you to reuse an existing one. My favorite library for that is ssreflect. It contains an ordinal n type family that corresponds to your BoundedNat, defined in fintype.v (doc here). There is a coercion from ordinal to nat so that you can readily reuse most operators on natural numbers transparently -- e.g. you can write i < j directly when i j : ordinal n.
Building terms of ordinal is more complicated, since it requires the proof argument. There is no best way of finding this proof, so the way to proceed depends on the application. For instance, adding a constant to a bounded nat is common enough to deserve a specialized operation in ssreflect:
rshift : forall m n, ordinal n -> ordinal (m + n)
One of the advantages of using ssreflect is that it comes with generic support for subset types like ordinal. For instance, there is a insub : nat -> option (ordinal n) function that succeeds if an only if its argument is bounded by n. This function works not only for nat and ordinal, but for any pair of types connected by the subtype interface: sT is a subtype of T if it is of the form {x : T | P x} for some boolean predicate P. Thus, you can manipulate subtypes with a consistent interface rather than rolling up your own each time.
I want to use Coq to define the following operator:
where formulae P and Q has 8 variables
For simplicity, we can regard each type of the variables as nat. However, I have no idea how to translate this operator in Coq. The operator s/tr denotes the substitute.
When I prove some theorem, my goal evolves as I apply more and more tactics. Generally speaking the goal tends to split into sub goals, where the subgoals are more simple. At some final point Coq decides that the goal is proven. How this "proven" goal may look like? These goals seems to be fine:
a = a. (* Any object is identical to itself (?) *)
myFunc x y = myFunc x y. (* Result of the same function with the same params
is always the same (?) *)
What else can be here or can it be that examples are fundamentally wrong?
In other words, when I finally apply reflexivity, Coq just says ** Got it ** without any explanation. Is there any way to get more details on what it actually did or why it decided that the goal is proven?
You're actually facing a very general notion that seems not so general because Coq has some user-friendly facility for reasoning with equality in particular.
In general, Coq accepts a goal as solved as soon as it receives a term whose type is the type of the goal: it has been convinced the proposition is true because it has been convinced the type that this proposition describes is inhabited, and what convinced it is the actual witness you helped build along your proof.
For the particular case of inductive datatypes, the two ways you are going to be able to proved the proposition P a b c are:
by constructing a term of type P a b c, using the constructors of the inductive type P, and providing all the necessary arguments.
or by reusing an existing proof or an axiom in the environment whose type you can get to match P a b c.
For the even more particular case of equality proofs (equality is just an inductive datatype in Coq), the same two ways I list above degenerate to this:
the only constructor of equality is eq_refl, and to apply it you need to show that the two sides are judgementally equal. For most purposes, this corresponds to goals that look like T a b c = T a b c, but it is actually a slightly more broad notion of equality (see below). For these, all you have to do is apply the eq_refl constructor. In a nutshell, that is what reflexivity does!
the second case consists in proving that the equality holds because you have other equalities in your context, nothing special here.
Now one part of your question was: when does Coq accept that two sides of an equality are equal by reflexivity?
If I am not mistaken, the answer is when the two sides of the equality are αβδιζ-convertible.
What this grossly means is that there is a way to make them syntactically equal by repeated applications of:
α : sane renaming of non-free variables
β : computing reducible expressions
δ : unfolding definitions
ι : simplifying matches
ζ : expanding let-bound expressions
[someone please correct me if more rules apply or if I got one wrong]
For instance some of the things that are not captured by these rules are:
equality of functions that do more or less the same thing in different ways:
(fun x => 0 + x) = (fun x => x + 0)
quicksort = mergesort
equality of terms that are stuck reducing but would be equal:
forall n, 0 + n = n + 0
Assume that I need to prove something like the following:
x: nat
(fun _ : nat => 0) = (fun y : nat => if beq_nat x y then 0 else 0)
Since y is not in the environment, it looks like I can't destruct on beq_nat x y to simplify the right-hand side. Is there a simple way to simplify expressions within an anonymous function?
Besides being able to massage two functions to look equal, is there a way to deduce that two functions are the same by showing that they produce the same value on all inputs?
EDIT: I realize that I might be asking for the impossible, since those functions are not the same, it's just that when applied to an argument they produce the same value. I'm not sure exactly how Coq interprets this.
I believe this is a case of what is referred to as functional extensionality, where you want to prove that two functions are extensionally equal (they behave the same from the caller's point of view).
You cannot prove it directly in Coq (since = is a definitioinal equality, it is not true), but if you wish to, you can require this module:
http://coq.inria.fr/stdlib/Coq.Logic.FunctionalExtensionality.html
which will provide you with axioms for functional extensionality. You can call the tactic extensionality y. which will give you access to the y.