I am sorry for asking so many Isabelle questions lately. Right now I have a type problem.
I want to use a type_synonym introduced in a AFP-theory.
type_synonym my_fun = "nat ⇒ real"
I have a locale in my own theory where:
fixes n :: nat
and f :: "my_fun"
and A :: "nat set"
defines A: "A ≡ {0..n}"
However, in my use case the output of the function f is always a natural number in the set {0..n}. I want to impose this as a condition (or is there a better way to do it?). The only way I found was to:
assumes "∀v. ∃ i. f v = i ∧ i ∈ A"
since
assumes "∀v. f v ∈ A"
does not work.
If I let Isabelle show me the involved types it seems alright to me:
∀v::nat. ∃i::nat. (f::nat ⇒ real) v = real i ∧ i ∈ (A::nat set)
But of course now I cannot type something like this:
have "f ` {0..10} ⊆ A"
But I have to prove this. I understand where this problem comes from. However, I do not know how to proceed in a case like this. What is the normal way to deal with it? I would like to use my_fun as it has the same meaning as in my theory.
Thank you (again).
If you look closely at ∀v::nat. ∃i::nat. (f::nat ⇒ real) v = real i ∧ i ∈ (A::nat set), you will be able to see the mechanism that was used for making the implicit type conversion between nat and real: it is the abbreviation real (this invokes of_nat defined for semiring_1 in Nat.thy) that appears in the statement of the assumption in the context of the locale.
Of course, you can use the same mechanism explicitly. For example, you can define A::real set as A ≡ image real {0..n} instead of A::nat set as A ≡ {0..n}. Then you can use range f ⊆ A instead of assumes "∀v. ∃ i. f v = i ∧ i ∈ A”. However, I doubt that there is a universally accepted correct way to do it: it depends on what exactly you are trying to achieve. Nonetheless, for the sake of the argument, your locale could look like this:
type_synonym my_fun = "nat ⇒ real"
locale myloc_basis =
fixes n :: nat
abbreviation (in myloc_basis) A where "A ≡ image real {0..n}"
locale myloc = myloc_basis +
fixes f :: "my_fun"
assumes range: "range f ⊆ A"
lemma (in myloc) "f ` {0..10} ⊆ A"
using range by auto
I want to impose this as a condition (or is there a better way to do
it?).
The answer depends on what is known about f. If only a condition on the range of f is known, as the statement of your question seems to suggest, then, I guess, you can only state is as an assumption.
As a side note, to the best of my knowledge, defines is considered to be obsolete and it is best to avoid using it in the specifications of a locale: stackoverflow.com/questions/56497678.
Related
The following expressions are almost identical:
value "(1,5) ∈ trancl {(1::nat,2::nat),(2,5)}"
value "(1,5) ∈ rtrancl {(1::nat,2::nat),(2,5)}"
However the first one is evaluated fine, and for the second one I get the following error:
Wellsortedness error:
Type nat not of sort {enum,equal}
No type arity nat :: enum
It seems that the error is caused by the identity relation:
value "(1::nat,5::nat) ∈ Id"
However the following code lemma doesn't help:
lemma Id_code [code]: "(a, b) ∈ Id ⟷ a = b" by simp
Could you please suggest how to fix it? Why it doesn't work from the scratch? Is it just an incompleteness of code lemmas or there are more fundamental reasons?
The problem becomes apparent when you look at the code equations for rtrancl with code_thms rtrancl:
rtrancl r ≡ trancl r ∪ Id
Here, Id is the identity relation, i.e. the set of all (x, x). If your type is infinite, both Id and its complement will also be infinite, and there is no way to represent that in a set with the Isabelle code generator's default set representation (which is as lists of either all the elements that are in the set or all the elements that are not in the set).
The code equation for Id reflects this as well:
Id = (λx. (x, x)) ` set enum_class.enum
Here, enum_class.enum comes from the enum type class and is a list of all values of a type. This is where the enum constraint comes from when you try to evaluate rtrancl.
I don't think it's possible to evaluate rtrancl without modifying the representation of sets in the code generator setup (and even then, printing the result in a readable form would be challenging). However, getting the code generator to evaluate things like (1, 5) ∈ rtrancl … is relatively easy: you can simply register a code unfold rule like this:
lemma in_rtrancl_code [code_unfold]: "z ∈ rtrancl A ⟷ fst z = snd z ∨ z ∈ trancl A"
by (metis prod.exhaust_sel rtrancl_eq_or_trancl)
Then your value command works fine.
Consider the following property:
lemma "finite {t. (c,s) ⇒ t}"
Which refers to the following big step semantics:
inductive gbig_step :: "com × state ⇒ state ⇒ bool" (infix "⇒" 55)
where
Skip: "(SKIP, s) ⇒ s"
| Assign: "(x ::= a, s) ⇒ s(x := aval a s)"
| Seq: "⟦(c1, s1) ⇒ s2; (c2, s2) ⇒ s3⟧ ⟹ (c1;;c2, s1) ⇒ s3"
| IfBlock: "⟦(b,c) ∈ set gcs; bval b s; (c,s) ⇒ s'⟧ ⟹ (IF gcs FI, s) ⇒ s'"
| DoTrue: "⟦(b,c) ∈ set gcs; bval b s1; (c,s1) ⇒ s2;(DO gcs OD,s2) ⇒ s3⟧
⟹ (DO gcs OD, s1) ⇒ s3"
| DoFalse: "⟦(∀ (b,c) ∈ set gcs. ¬ bval b s)⟧ ⟹ (DO gcs OD, s) ⇒ s"
To me it is obvious that the property holds by induction on the big step relation. However, I can not get it out of the set, so I cannot effectively induct on it.
How could I do this?
Finiteness is nothing that you could prove directly with the induction rule of an inductive predicate. The problem is that looking at an individual run (as does the induction rule) does not say anything about the branching behaviour, which must also be finite for the statement to hold.
I see two approaches to proving finiteness:
Model the derivation tree explicitly as a datatype in Isabelle/HOL and prove that it adequately represent the derivation trees behind inductive. Then prove that the tree has finitely many leaves (by induction on the tree). If you design the datatype such that the states in the leaves are a type parameter, then the corresponding set function generated by the datatype package is what you want to prove to be finite. (Note that you cannot prove finiteness by the induction rule of the set function, because that would again be just a single run.)
Look at the internal construction of the inductive definition. It is defined as the least fixpoint of a functional. You can get access to these internals by putting the inductive definition into a context in which [[inductive_internals]] is declared. Then you can prove that the functional preserves finiteness in a single step and then lift that through the induction.
The proof argument in both approaches is similar. The explicit datatype in #1 simply reifies the fixpoint argument of #2. So you can think of #1 as a deep embedding of #2. Of course, you can also re-derive the internal construction (in a more suitable format) just from the introduction and induction theorems and then follow approach #2.
I would try to do precisely this as your semantics is small. For a large real-world semantics, it might make sense to spend the effort to automate step #2 in ML.
I'm attempting to formalize a series of proofs about topology from a book [1] in Isabelle.
I want to encode the idea that a topological space (X,T) consists of a set X of "points" (elements of some arbitrary type 'a), and a set of subsets of X, called T, such that:
A1. if an element p is in X, then there exists at least one set N in T that also contains p.
A2. if sets U and V are in T, and if p∈(U∩V), then there must exist at a set N in T where N⊆(U∩V) and x∈N. (If two sets intersect, then there must be a neighborhood that covers the intersection.).
Currently I have the following definition:
class topspace =
fixes X :: "'a set"
fixes T :: "('a set) set"
assumes A1: "p∈X ≡ ∃N∈T. p∈N"
assumes A2: "U∈T ∧ V∈T ∧ x∈(U∩V) ⟹ ∃N∈T. x∈N ∧ N⊆(U∩V)"
begin
(* ... *)
end
So far, so good. I'm able to add various definitions and prove various lemmas and theorems about hypothetical topspace instances.
But how do I actually create one? Unless I'm misinterpreting things, the examples I've seen so far for the instance and instantiate keywords all seem to be been about declaring that one particular abstract class (or type or locale) is an instance of another.
How do I tell Isabelle that a particular pair of sets (e.g. X={1::int, 2, 3}, T={X,{}}) form a topspace?
Likewise, how can I use my definition to prove that X={1::int, 2, 3}, T={} does not fit the requirements?
Finally, once I show that a particular concrete object X meets the definition of a topspace, how do I tell Isabelle to now make use of all the definitions and theorems I've proven about topspace when proving things about X?
BTW, I'm using class because I don't know any better. If it's not the right tool for the job, I'm happy to do something else.
[1]: A Bridge to Advanced Mathematics by Dennis Sentilles
I've made some progress here: a class is a special type of locale, but it isn't necessary for this sort of usage, and using the locale keyword directly simplifies the situation a bit. Every locale has an associated theorem that you can use to instantiate it:
locale topspace =
fixes X :: "'a set"
fixes T :: "('a set) set"
assumes A1 [simp]: "x∈X ≡ ∃N∈T. x∈N"
assumes A2 [simp]: "U∈T ∧ V∈T ∧ x∈(U∩V) ⟹ ∃N∈T. x∈N ∧ N⊆(U∩V)"
theorem
assumes "X⇩A={1,2,3::int}" and "T⇩A={{}, {1,2,3::int}}"
shows "topspace X⇩A T⇩A"
proof
show "⋀U V x. U∈T⇩A ∧ V∈T⇩A ∧ x∈U∩V ⟹ ∃N∈T⇩A. x∈N ∧ N⊆U∩V"
and "⋀x. x∈X⇩A ≡ ∃N∈T⇩A. x∈N" using assms by auto
qed
If we want to use definition for declarations, the proof goal becomes a bit more complex, and we need to use the unfolding keyword. (The locales.pdf that comes with isabelle covers this, but I'm not sure I'm not yet able to explain it in my own words). Anyway, this works:
experiment
begin
definition X⇩B where "X⇩B={1,2,3::int}"
definition T⇩B where "T⇩B={{}, {1,2,3::int}}"
lemma istop0: "topspace X⇩B T⇩B" proof
show "⋀U V x. U∈T⇩B ∧ V∈T⇩B ∧ x∈U∩V ⟹ ∃N∈T⇩B. x∈N ∧ N⊆U∩V"
and "⋀x. x∈X⇩B ≡ ∃N∈T⇩B. x∈N" unfolding X⇩B_def T⇩B_def by auto
qed
end
I believe it's also possible, and possibly preferable, to do all this work inside of a sub-locale, but I haven't quite worked out the syntax for this.
Although locales are implemented in the calculus itself and hence their predicates can be used in any regular proposition, this is usually not recommended. Instead, you should instantiate locales using e.g. interpretation, as in the following example.
locale topspace =
fixes X :: "'a set"
fixes T :: "('a set) set"
assumes A1 [simp]: "x∈X ⟷ (∃N∈T. x∈N)"
assumes A2 [simp]: "U∈T ∧ V∈T ∧ x∈(U∩V) ⟹ ∃N∈T. x∈N ∧ N⊆(U∩V)"
context
fixes X⇩A T⇩A
assumes X⇩A_eq: "X⇩A = {1, 2, 3 :: int}"
and T⇩A_eq: "T⇩A = {{}, {1, 2, 3 :: int}}"
begin
interpretation example: topspace X⇩A T⇩A
by standard (auto simp add: X⇩A_eq T⇩A_eq)
lemmas facts = example.A1 example.A2
end
thm facts
Whether this pattern really fits for your needs depends on your application; if you just want to have a predicate, it is better to define it directly without using locale at all.
Note: there is really need to the Pure equality »≡«; prefer HOL equality »=«, or its syntactic variant »⟷«.
I am trying to understand the lemma below.
Why is the ?y2 schematic variable introduced in exI?
And why it is not considered in refl (so: x = x)?
lemma "∀x. ∃y. x = y"
apply(rule allI) (* ⋀x. ∃y. x = y *)
thm exI (* ?P ?x ⟹ ∃x. ?P x *)
apply(rule exI) (* ⋀x. x = ?y2 x *)
thm refl (* ?t = ?t *)
apply(rule refl)
done
UPDATE (because I can't format code in comments):
This is the same lemma with a different proof, using simp.
lemma "∀x. ∃y. x = y"
using [[simp_trace, simp_trace_depth_limit = 20]]
apply (rule allI) (*So that we start from the same problem state. *)
apply (simp only:exI)
done
The trace shows:
[0]Adding rewrite rule "HOL.exI":
?P1 ?x1 ⟹ ∃x. ?P1 x ≡ True
[1]SIMPLIFIER INVOKED ON THE FOLLOWING TERM:
⋀x. ∃y. x = y
[1]Applying instance of rewrite rule "HOL.exI":
?P1 ?x1 ⟹ ∃x. ?P1 x ≡ True
[1]Trying to rewrite:
x = ?x1 ⟹ ∃xa. x = xa ≡ True <-- NOTE: not ?y2 xa or similar!
[2]SIMPLIFIER INVOKED ON THE FOLLOWING TERM:
x = ?x1
[1]SUCCEEDED
∃xa. x = xa ≡ True
So apparently simp and rule handles exI differently. And the remaining question is: what is the mechanical (programmatical) reasoning behind rule's behavior.
When you use rule thm for some fact thm, Isabelle performs higher-order unification of the conclusion of thm with the current goal. If there is a unifier, it is used to instantiate both the goal and the conclusion of the theorem, and then resolution is performed (i.e. the goal is replaced with the assumptions of thm).
This means that:
Schematic variables in the goal can be instantiated by rule through unification
Variables that appear only in the assumptions of thm will not be instantiated by the unification and will therefore remain schematic. That way, you end up with schematic variables in your new goals. Such variables can be seen as existential in some sense, because the conclusion of thm holds if you can prove the assumptions for just one arbitrary value.
In the case of exI, you have ?P ?x ⟹ ∃x. ?P x. When you apply rule exI, the variable ?P is instantiated to λy. x = y, but the variable ?x appears only in the assumptions of exI, so it remains schematic. This means that you can pick any value you want for ?x later on in your proof.
To be more precise, you end up with ⋀x. x = ?y2 x as your goal. You might ask ‘Why not just ⋀x. x = ?y2?’ That would mean that you have to show that x equals some fixed value y2 for all possible values of x. That is obviously not true in general. ⋀x. x = ?y2 x means you have to show that every x equals some y2 that may depend on x – or, equivalently, that there is a function y2 that, when given x, outputs x.
Of course, there is such a function and it is simply the identity function λx. x. That is precisely what ?y2 gets instantiated to when you apply rule refl: the goal x = ?y2 x is unified with the conclusion of refl ?t = ?t and you end up with ?t = x and ?y2 = λx. x, and since refl has no assumptions, this resolution finishes the proof.
I am not entirely sure what you mean with ‘And why it is not considered in refl?’, but I hope that I have answered your questions.
Get a more complete answer from an expert, but I give a short, brief answer to your second part.
The great thing about Isabelle is that it provides many different ways to prove a problem.
Your new question is similar to L.Paulson's comment on FOM: you moved the goal post by switching the question to rule vs. simp:
http://www.cs.nyu.edu/pipermail/fom/2015-October/019312.html
Getting a basic understanding of simp is actually a much easier goal to pursue, or I wouldn't be adding my reponse here.
rule and natural deduction
The use of rule is the use of natural deduction (ND), where most people aren't up to speed on ND. The use of ND requires understanding ND, so questions like your first question can lead to a non-simple answer, because anything informative can't be a one-liner answer, especially due to things like schematic variables (which you asked about), resolution, unification, rewriting, etc.
Do a search on natural deduction and you'll find the standard wiki page about it. There are numerous books on natural deduction, though they get swamped in searches on "logic" due to first-order logic books. A popular book is Logic in Computer Science, 2nd, by Huth and Ryan.
If you study ND, you'll see that exI matches one of the ND rules.
I have yet to take the time to come up to speed on ND, because I keep making progress without having more than a basic understanding of ND.
Sledgehammer, and auto-methods auto, simp, blast, induct, cases, etc., and Sledgehammer's use of some of those, keep me from finding the time to become good with natural decution.
Answer's like M.Eberl's, though not simple explanations, help me absorb a little here and a little there.
Simp, I think of it as simple substitution (rewriting)
The mechanics behind simp is really simple, compared to natural deduction. You define a formula and prove it:
lemma foo [simp]: "left_hand_side = right_hand_side"
In the proof of another theorem, when simp is invoked in one way or another, or foo is unfolded, where there is left_hand_side, it's replaced with right_hand_side. It's just classic mathematical substitution.
I suppose it could also be "rewriting", but I don't know anything about rewriting, other than they talk about it.
There are lots of details about how and whether one should set things up automatically (to prevent looping), like with [simp] or declare foo_def [simp add], but that's just details along the line of normal programming.
I would like to reason about functions that choose one element from a finite set.
I tried to define a predicate that tells me whether some given function is such a “chooser” function:
definition chooser :: "('a set ⇒ 'a) ⇒ bool"
where "chooser f ⟷ (∀ A . finite A ⟶ f A ∈ A)"
Actually those finite sets from which I'd like to choose elements are of a concrete type, but putting a concrete type in 'a's place causes the same trouble.
I have also tried to omit finite A, but the sets I'm dealing with are finite, and I don't even want to think about the axiom of choice here.
Now this definition seems to be inconsistent:
lemma assumes "chooser f" shows "False" using assms chooser_def by force
How can I define chooser in a reasonable way? I would like to use it as follows:
assume "finite A"
moreover assume "chooser f"
moreover assume "choice = f A"
ultimately have "choice ∈ A" by ???
Most of the time it merely matters that a member of the set is chosen, not how it is chosen.
Background: I'd like to formalise tie-breakers in auctions (section 4 of this paper). Suppose there are two highest bids for the item being auctioned, we need to arbitrarily choose the one bidder who should win the auction.
Here is, BTW, a really minimal example (which is a bit harder to understand):
lemma "(∀ A . finite A ⟶ f A ∈ A) ⟹ False" by force
I merely provide the details based on Brian's comment that a choice function is defined only for a collection of non-empty sets.
From the Wikipedia entry on Choice_function:
A choice function (selector, selection) is a mathematical function f that is defined on some collection X of nonempty sets and assigns to each set S in that collection some element f(S) of S.
By now, you probably already have what you need from Brian's coment, but I do this anyway. The definition of chooser only needs the requirement that the set isn't empty:
definition chooser :: "('a set => 'a) => bool" where
"chooser f <-> (!A. A ~= {} --> f A ∈ A)"
theorem "(finite A & A ~= {} & chooser f) ==> (f A ∈ A)"
by(metis chooser_def)
theorem "(A ~= {} & chooser f) ==> (f A ∈ A)"
by(metis chooser_def)
You said that you don't want to use the Axiom of Choice, but a standard choice function demonstrates a good template to follow, not that you need it.
definition choice :: "'a set => 'a" where
"choice T = (SOME x. x ∈ T)"
theorem "T ~= {} ==> choice T ∈ T"
by(unfold choice_def, metis ex_in_conv someI
--GC