isabelle


How to manage all the various proof methods


Is there a "generic" informal algorithm that users of Isabelle follow, when they are trying to prove something that isn't proved immediately by auto or sledgehammer? A kind of general way of figuring out, if auto needs additional lemmas, formulated by the user, to succeed or if better some other proof method is used.
A related question is: Is there maybe a table to be found somewhere with all the proof methods together with the context in which to apply them? When I'm reading through the Programming and Proving tutorial, the description of various methods (respectively variants of some methods, such as the many variant of auto) are scattered through the text, which constantly makes me go back and for between text and Isabelle code (which also leads to forgetting what exactly is used for what) and which results in a very inefficient workflow.
No, there's no "generic" informal way. You can use try0 which tries all standard proof methods (like auto, blast, fastforce, …) and/or sledgehammer which is more advanced.
After that, the fun part starts.
Can this theorem be shown with simpler helper lemmas? You can use the command "sorry" for assuming that a lemma is true.
How would I prove this on a piece of paper? And then try to do this proof in Isabelle.
Ask for help :) Lots of people on stack overflow, #isabelle on freenode and the Isabelle mailing list are waiting for your questions.
For your second question: No, there's no such overview. Maybe someone should write one, but as mentioned before you can simply use try0.
ammbauer's answer already covers lots of important stuff, but here are some more things that may help you:
When the automation gets stuck at a certain point, look at the available premises and the goal at that point. What kind of simplification did you expect the system to do at that point? Why didn't it do it? Perhaps the corresponding rule is just not in the simp set (add it with simp add:) or some preconditions of the rule could not be proved (in that case, add enough facts so that they can be proved, or do it yourself in an additional step)
Isar proofs are good. If you have some complicated goal, try breaking it down into smaller steps in Isar. If you have bigger auxiliary facts that may even be of more general interest, try pulling them out as auxiliary lemmas. Perhaps you can even generalise them a bit. Sometimes that even simplifies the proof.
In the same vein: Too much information can confuse both you and Isabelle. You can introduce local definitions in Isar with define x where "x = …" and unfold them with x_def. This makes your goals smaller and cleaner and decreases the probability of the automation going down useless paths in its proof search.
Isabelle does not automatically unfold definitions, so if you have a definition, and you want to unfold it for a proof, you have to do that yourself by using unfolding foo_def or simp add: foo_def.
The defining equations of functions defined with fun or primrec are unfolding by anything using the simplifier (simp, simp_all, force, auto) unless the equations (foo.simps) have manually been deleted from the simp set. (by lemmas [simp del] = foo.simps or declare [simp del] foo.simps)
Different proof methods are good at different things, and it takes some experience to know what method to use in what case. As a general rule, anything that requires only rewriting/simplification should be done with simp or simp_all. Anything related to classical reasoning (i.e. first-order logic or sets) calls for blast. If you need both rewriting and classical reasoning, try auto or force. Think of auto as a combination of simp and blast, and force is like an ‘all-or-nothing’ variant of auto that fails if it cannot solve the goal entirely. It also tries a little harder than auto.
Most proof methods can take options. You probably also now add: and del: for simp and simp_all, and the equivalent simp:/simp del: for auto. However, the classical reasoners (auto, blast, force, etc.) also accept intro:, dest:, elim: and the corresponding del: options. These are for declaring introduction, destruction, and elimination rules.
Some more information on the classical reasoner:
An introduction rule is a rule of the form P ⟹ Q ⟹ R that should be used whenever the goal has the form R, to replace it with P and Q
A destruction rule is a rule of the form P ⟹ Q ⟹ R that should be used whenever a fact of the form P is in the premises to replace to goal G with the new goals Q and R ⟹ G.
An elimination rule is something like thm exE (elimination of the existential quantifier). These are like a generalisation of destruction rules that also allow introducing new variables. These rules often appear in this like case distinctions.
The classical reasoner used by auto, blast, force etc. will use the rules in the claset (i.e. that have been declared intro/dest/elim) automatically whenever appropriate. If doing that does not lead to a proof, the automation will backtrack at some point and try other rules. You can disable backgracking for specific rules by using intro!: instead of intro: (and analogously for the others). Then the automation will apply that rule whenever possible without ever looking back.
The basic proof methods rule, drule, erule correspond to applying a single intro/dest/elim rule and are good for single step reasoning, e.g. in order to find out why automatic methods fail to make progress at a certain point. intro is like rule but applies the set of rules it is given iteratively until it is no longer possible.
safe and clarify are occasionally useful. The former essentially strips away quantifiers and logical connectives (try it on a goal like ∀x. P x ∧ Q x ⟶ R x) and the latter similarly tries to ‘clean up’ the goal. (I forgot what it does exactly, I just use it occasionally when I think it might be useful)

Related Links

The order of premises
set integrable with functions multiplication
Locale import two classes
Find all Pairs definition
Simplify meta-universally quantified assumptions with equality
What is the syntax to use Map.thy
Collecting locally fixed parameters using Eisbach
Why does simp “fail to apply initial proof method” where blast succeeds with the same facts?
Proving a theorem about parser combinators
Manually adding an assumption to the simplifier (Isabelle)
Proving something is an instance of a locale in Isabelle
Defining multiple constants in an integral
Definition without recursion, by cases, in Isabelle
Using a definition to produce an specific example of a locale in Isabelle
Should I use universal quantification in lemma formulation?
Using syntax/translations wiith locales

Categories

HOME
clips
magnific-popup
tizen
stock
relay
google-oauth
jgroups
disassembler
alpha
mouse
ios-charts
upload
add
tomcat6
google-cloud-spanner
circuit
iron-router
dynamics-crm-online
clojurescript
ghc
progressive-web-apps
pc
shared-hosting
viewport
reverse-proxy
visjs
object-detection
excel-2007
google-search-api
telerik-reporting
mmap
centos6.5
log4js-node
msys2
gsmcomm
madlib
fabric8
uisplitview
airconsole
uiswipegesturerecognizer
bytecode-manipulation
revolution-slider
x11-forwarding
lto
neuroscience
abstract-class
uft-api
eclipse-scout
sql-server-agent
gulp-sourcemaps
no-www
reactive-cocoa-5
businessworks
convertapi
network-flow
zip4j
errordocument
domain-model
togetherjs
tactic
epson
cudafy.net
ctest
impresspages
clang-static-analyzer
qcustomplot
python-stackless
yaws
ipconfig
xpath-1.0
wapiti
intellij-14
mutation-observers
service-accounts
ami
web-controls
nsbutton
device-manager
html-helper
elliptic-curve
concurrent-collections
app42
terminal-services
farseer
jsctypes
cdc
dir
flash-builder4.5
excel-2003
rabl
random-seed
mqx
sharp-repository
mt
bluepill
cascalog
pendrive
gnu-prolog
hamachi
android-sdk-2.1
kdbg
backcolor
mediarss
w3wp
uiq3

Resources

Mobile Apps Dev
Database Users
javascript
java
csharp
php
android
MS Developer
developer works
python
ios
c
html
jquery
RDBMS discuss
Cloud Virtualization
Database Dev&Adm
javascript
java
csharp
php
python
android
jquery
ruby
ios
html
Mobile App
Mobile App
Mobile App