Here is my problem:
Why does this work specifically for step 7, p and p implies r. I can understand how to show r implies not q. Can someone also tell me what modus ponens means and how it's used in the context?
Here are the relevant claims from the image:
p (given)
p -> r (given)
(3-6 snipped)
r (modus ponens 1, 2)
The Wikipedia article on Modus Ponens explains this pretty well. Quoting with some parts removed/changed:
The argument form has two premises (hypothesis). The first premise is that P, the antecedent of the conditional claim, is true. The second premise is the "if–then" or conditional claim, namely that P implies R. From these two premises it can be logically concluded that R, the consequent of the conditional claim, must be true as well.
An example of an argument that fits the form modus ponens:
Today is Tuesday. (P)
If today is Tuesday, then John will go to work. (P -> R)
Therefore, John will go to work. (R)
Modus ponens is the rule of inferences used to generate new logical statements from valid premises.
Related
I've been trying to understand what Set is after encountering it in Adam Chlipala's book in addition to this great discussion in SO. His first example definition binary ops using Set:
Inductive binop : Set := Plus | Times.
in that book he says:
Second, there is the : Set fragment, which declares that we are defining a datatype that should be thought of as a constituent of programs.
Which confuses me. What does Adam mean here?
In addition, I thought that some additional concrete examples would help my understanding. I am not an expert of Coq so I am not sure what type of examples would help but something simple and very concrete/grounded might be useful.
Note, I have seen that Set is the first "type set" in a the type hierarchy e.g. Set = Type(0) <= Type = Type(1) <= Type(2) <= ... . I guess this sort of makes sense intuitively like I'd assume nat \in Type and all usual programming types to be in it but not sure what would be in Type that wouldn't be in Set. Perhaps recursive types? Not sure if that is the right example but I am trying to wrap my head around what this concept means and it's conceptual (& practical) usefulness.
Though Set and Type are different in Coq, this is mostly due to historical reasons. Nowadays, most developments do not rely on Set being different from Type. In particular, Adam's comment would also make sense if you replace Set by Type everywhere. The main point is that, when you want to define a datatype that you can compute with during execution (e.g. a number), you want to put it in Set or Type rather than Prop. This is because things that live in Prop are erased when you extract programs from Coq, so something defined in Prop would end up not computing anything.
As for your second question: Set is something that lives in Type, but not in Set, as the following snippet shows.
Check Set : Type. (* This works *)
Fail Check Set : Set.
(* The command has indeed failed with message: *)
(* The term "Set" has type "Type" while it is expected to have type *)
(* "Set" (universe inconsistency: Cannot enforce Set+1 <= Set). *)
This restriction is in place to prevent paradoxes in the theory. This is pretty much the only difference you see between Set and Type by default. You can also make them more different by invoking Coq with the -impredicative-set option:
(* Needs -impredicative-set; otherwise, the first line will also fail.*)
Check (forall A : Set, A -> A) : Set.
Universe u.
Fail Check (forall A : Type#{u}, A -> A) : Type#{u}.
(* The command has indeed failed with message: *)
(* The term "forall A : Type, A -> A" has type "Type#{u+1}" *)
(* while it is expected to have type "Type#{u}" (universe inconsistency: Cannot enforce *)
(* u < u because u = u). *)
Note that I had to add the Universe u. declaration to force the two occurrences of Type to be at the same level. Without this declaration, Coq would silently put the two Types at different universe levels, and the command would be accepted. (This would not mean that Type would have the same behavior as Set in this example, since Type#{u} and Type#{v} are different things when u and v are different!)
If you're wondering why this feature is useful, it is not by chance. The overwhelming majority of Coq developments does not rely on it. It is turned off by default because it is incompatible with a few axioms that are generally considered more useful in Coq developments, such as the strong law of the excluded middle:
forall A : Prop, {A} + {~ A}
With -impredicative-set turned on, this axiom yields a paradox, while it is safe to use by default.
I am struggling with the plus operator between two propositions (maybe types) in Coq. I already could figure out this is something like "or" (maybe "xor") and I think it says that something is decidable but I cannot understand the complete meaning of it, and where does this sign come from (in classical mathematics).
P. S. Of course I already googled and researched but couldn't find the complete sophisticated answer I want.
That's the sum datatype, where A + B is basically A or B. The main difference with A \/ B is that it lives in Type, so it has computational content. That is to say, given A \/ B you cannot produce a boolean such that if A then true else false.
Another way to see it is that for A B : Prop, A + B -> A \/ B holds, but not the converse.
Prop is a special, impredicative sort in Coq; I recommend reading the manual about it.
I've seen a variable scope propagation to the inner function in previous versions of k. See eval: {[t;c]{x*t+y}/c} in http://www.math.bas.bg/bantchev/place/k.html
But if I try to do the same in modern k, I get an error:
KDB+ 3.6 2018.05.17 Copyright (C) 1993-2018 Kx Systems
q)\
{[k]{x*x}k}3
9
{[k]{x*x+k}k}3
'k
[2] k){x*x+k}
^
)
So why this error happens? Is such variable scope propagation 'banned' in modern q?
Indeed, k4, the most recent implementation of k by kx does not support closures. In fact, the article you refer to does mention that in a section called "Changes to the Language":
K4/q is a change over K3 in a number of significant ways, such as:
...
Nested functions in K4 and q cannot refer to surrounding function's local
variables. (Often, the lack of this ability can be circumvented by
making use of function projection.)
It turns out the lack of support of lexical scoping has not always been the case. Although the only officially documented language nowadays is q, one can still find a reference manual for k2, an implementation of k circa 1998, for example here: http://www.nsl.com/k/k2/k295/kreflite.pdf. Section "Local functions" on page 158 reads:
Local Functions
Suppose that the function g is defined within the body of another
function f and uses the variable x in its definition, where x is local
to f. Then x is a constant in g, not a variable, and its value is the
current one when g is defined. For example, if:
f:{b:3; g:{b}; b:4; g[]}
The value of f is the value of the local function g, which turns out to be 3, the value of b when g is defined,
not the subsequent value 4.
f[]
3
(I highly recommend reading the whole document, by the way).
I don't know why the support of closures was dropped but I think it was because of performance reasons, especially during interprocess communications.
I have question as follows: A set A is defined and total function X with invariant type
X ∈ A --> BOOL
and an event A_setSate:
A_setSate =
WHEN X(A) = TRUE
THEN X(A) := FALSE
the problem is that the proof obligation event preservation (INV) of A_setState cannot preserve the invariant X∈ A--> BOOL:
I know it is because of the invariant is not strong enough, but I could not create a stronger invariant.
full example : Example snipping
The example looks correct.
Please check if the Atelier B provers are installed, the Rodin Handbook contains instructions for this.
(This answer had been updated after some clarifications in the comments.)
I am formalizing a grammar which is essentially one over boolean expressions. In coq, you can get boolean-like things in Prop or more explicitly in bool.
So for example, I could write:
true && true
Or
True /\ True
The problem is that in proofs (which is what I really care about) I can do a case analysis in domain bool, but in Prop this is not possible (since all members are not enumerable, I suppose). Giving up this tactic and similar rewriting tactics seems like a huge drawback even for very simple proofs.
In general, what situations would one choose Prop over bool for formalizing? I realize this is a broad question, but I feel like this is not addressed in the Coq manual sufficiently. I am interested in real world experience people have had going down both routes.
There are lots of different opinions on this. My personal take is that you are often better off not making this choice: it makes sense to have two versions of a property, one in Prop, the other one in bool.
Why would you want this? As you pointed out, booleans support case analysis in proofs and functions, which general propositions do not. However, Prop is more convenient to use in certain cases. Suppose you have a type T with finitely many values. We can write a procedure
all : (T -> bool) -> bool
that decides whether a boolean property P : T -> bool holds of all elements of T. Imagine that we know that all P = true, for some property P. We might want to use this fact to conclude that P x = true for some value x. To do this, we need to prove a lemma about all:
allP : forall P : T -> bool,
all P = true <-> (forall x : T, P x = true)
This lemma connects two different formulations of the same property: a boolean one and a propositional one. When reasoning about all in a proof, we can invoke allP to convert freely between the two. We can also have different conversion lemmas:
allPn : forall P,
all P = false <-> (exists x, P x = false)
In fact, we are free to choose any Coq proposition whatsoever to relate to a boolean computation (as long, of course, as we can prove that the two are logically equivalent). For instance, if we would like to have a custom induction principle associated with a boolean property, we can look for an equivalent formulation as an inductively defined proposition.
The Mathematical Components library is a good example of development that follows this style. Indeed, because it is so pervasive there, the library provides a special view mechanism for writing conversion lemmas like the one above and applying them. In plain Coq, we can also use the rewrite tactic to apply logical equivalences more conveniently.
Of course, there are many situations where it does not make sense to have two formulations of the same property. Sometimes, you are forced to use Prop, because the property you care about is undecidable. Sometimes, you might feel that you wouldn't gain anything by writing your property in Prop, and may keep it only as a boolean.
In addition to the Software Foundations chapter linked above, this answer discusses the difference between bool and Prop in more depth.