Proof Assistant GUI "Derive"
Feature
See also:
Proof Assistant User Guide
ProofAssistantGUIQuickHOWTO.html
ProofAssistantGUIDetailedInfo.html
StepUnifier.html
WorkVariables.html
PageLocalRef.mmp
StepSelectorSearch.html
UnifyEraseAndRederiveFormulas.html
BottomUpProving-ByNormMegill.html
Quick Explanation: Given
RefX, Derive solves for
unknowns in a proof step (imagine equation RefX(hypY,
..., hypZ) = formulaA).
- Derive is an integral part of the Unification process
- Derive is automatically invoked when an assertion Ref label is input on a derivation
step and fewer Hyp entries are
provided than needed for the Ref
(not counting "
?
"s),
and/or the step's Formula is
omitted (Formula is always
mandatory and cannot be derived on the 'qed
' proof step).
- Derive attempts to generate an omitted Formula and/or the step's Hypotheses.
- Insufficient information may result in Work Variables (written
as
&W1, &C1, &S1
, for the first 'wff
',
'class
' and 'set
' variables, respectively) in
the output Formula and/or Hypotheses.
- Hypothesis steps are generated if the derived hypothesis formulas
are not already present in the proof.
- Generated hypotheses are automatically sent through the
Unification process unless they contain Work Variables.
Purpose:
- To satisfy expert users of mmj2's Proof
Assistant GUI by partially solving the problem of correctly entering
certain
long and complicated formulas, the new Derive Feature
generates missing proof step formulas using input Ref labels. This is the
inverse of the normal Unification process of finding a matching
assertion Ref label for an
input formula and its associated hypotheses.
- Also,
to assist users in developing proofs by reasoning backwards from
conclusion to premisses, proof
step hypotheses are automatically
generated and/or linked to previous proof steps when the user supplies a Ref label on a Derivation proof
step and an insufficient number of Hyp entries. Note: "
?
"s may be used as place holders
signifying specific missing Hyps
within the Step:Hyp:Ref. This powerful
capability complements the new formula generation function and aids in
the
creation of proofs for theorems that are so insanely complex that even
typing in the formulas correctly by hand
is a superhumanly difficult task :)
Motivations:
- Typing Metamath formulas by hand is somewhat error prone and
difficult, especially for long formulas. Part of the reason for this is
that Metamath has no built-in grammar or syntax beyond the requirements
of the input .mm file format. This is a feature, not a bug. The
downside is that there are no notational
short-cuts; outer parentheses cannot be skipped and extra parentheses
are not tolerated. Given that there may be dozens of syntax axioms used
to build formulas and that even a single typing error generates
an error message, the user may find it difficult to even input
derivations, much less prove them! At some point a "Formula Builder"
helper screen may be added to the mmj2 Proof Assistant GUI, but until
then, the new Derive Feature will be useful. Note: the File/New
menu option that is used to begin a new proof initializes the Proof
Text area with the specified Theorem's hypotheses and conclusion proof
steps, so the remaining challenge is to enter derivation steps.
- The new Derive Feature provides an educational and
perhaps useful "what if?" capability allowing the user to easily answer
questions such as, "Given a specific formula and
assertion Ref
label, what hypotheses do I need to obtain/prove in order to justify
this derivation proof step?" Or, "If a specific assertion (Ref) is applied to a set of
hypotheses (which may be incomplete), what formula is derived?"
Limitations:
- The mmj2 Proof Assistant GUI requires that each derivation proof
step Ref label specify an
assertion -- logical axiom or theorem -- in the input Metamath .mm
file. The Ref,
together with the associated hypotheses may be viewed as being a
function call which generates the proof step formula. For example,
treating the modus ponens axiom as a function with arguments '
|- A
' and '|- ( A -> B )
' yields "ax-mp
('|- A
', '|- ( A -> B )
') = '|- B
'". In this case, the Ref, ax-mp
,
together with the hypothesis arguments completely specify and determine
the contents of the resulting formula. However, the new Derive Feature
allows the hypotheses to be incompletely specified -- missing
hypotheses are designated with "?
"
or are simply omitted. In these cases the output formula will, of
course, be incompletely specified as well! So, "ax-mp
('|- A
', '?
') = '|- ?
'".
(A similar situation arises for generated hypotheses.) This is a
feature, not a bug. But to properly present the unknowns in the
generated formulas, the new Derive Feature needs to be able to present
the un-determined variables in a helpful way. The Metamath Proof
Assistant uses "$1
", "$2
",
etc. for un-determined variables, so the Proof Assistant GUI will
follow suit, but outputs them as "&W1
",
"&S1
", "&C1
", etc. so that the Type Code
of the un-determined variable/sub-expression can be inferred from the
variable name ("&W
n" stands for "wff
",
"&C
n" stands for "class
"
and "&S
n" stands for "set
"
(mmj2 has a RunParm allowing the user
to specify an alternate naming scheme for Work
Variables.) (Note: in some cases it may appear obvious to
the user that a generated "&W1
"
variable can be unified with a sub-formula of some previous step(s) --
and it is natural to ask why doesn't the program just go ahead and
figure out the obvious substitution. The answer? Because that would
require an entirely new unification search process inside the Derive
Feature, as well as additional intelligence that is not programmed into
the code...)
- The
mmj2 Proof Assistant GUI respects the order of input hypotheses for a
derivation proof step during unification, but if the given order does
not yield a consistent set of variable substitutions for a Ref assertion, the program
methodically tests other sequences and dynamically rearranges its input
Hyp's. For example, if the
user inputs Hyp "
1,2,3
" referring to previous steps
numbered 1
, 2
, and 3
, but the referenced steps do not
unify with the Ref's 1st, 2nd,
and 3rd hypotheses, the program seeks an alternate arrangement, such as
"3,1,2
".
In some cases, there may be multiple satisfactory sequences of
hypotheses, which is one reason why the program gives the user's
initial input order priority. For example, assume hypotheses "|- A
" and "|- B
" for assertion "|- ( A -> B )
".
In this example, both possible sequences of hypotheses will satisfy the
requirements of unification! Now consider the situation where the user
does not completely specify the hypotheses, possibly with one or more "?
"s in the Hyp
sub-field. With incompletely specified hypotheses, the situation is
even more ambiguous for the program's attempt to deduce the correct
sequence of hypotheses! There is no perfect solution to this problem,
but the Proof Assistant GUI will continue to respect the given Hyp order and seek an alternate
sequence only if the given order fails unification. Thus, if the user
inputs "?,3,?
",
the program will attempt unification of the 3rd proof step with the
Ref's 2nd hypothesis before trying the alternatives. (On the plus side,
since hypothesis generation is performed only when a Ref
label is input, it may be assumed that the user has access to or
knowledge of the Ref assertions hypotheses and their order -- and can
use trial and error, if necessary.)
- In some cases after a proof has been completely developed, with
successful unification of the 'qed' step, Work Variables will still be
present in the formulas of some of the proof steps. These are
"leftovers" or "placeholders", and must be converted to optional/dummy
variables within the scope of the theorem being proved. mmj2 attempts
to convert leftover Work Variables to actual "dummy" variables, but in
some cases the algorithm is not smart enough to finish the job,
generally because there are not enough optional/dummy variables
available within the scope of the theorem being proved. To get rid of
the leftover Work Variables it is possible to add more optional/dummy
variables within the scope of the theorem, though this requires
updating the input .mm file and restarting mmj2 (after saving the Proof
Worksheet in progress!) Alternatively, the user can manually change the
Work Variables (say, change "
&W1
" to "th
")
-- this is not as hard as it may seem because mmj2 will apply the
changes to every occurrence of a Work Variable, assuming unification
was successful, and furthermore, elimination of one leftover Work
Variable may eliminate the shortfall in available optional/dummy
variables within the scope of the theorem.
- Even
with the new Derive Feature, the mmj2 Proof Assistant GUI is far from
being the ultimate tool for proving theorems. And, in fact, there is no
proof that the Proof Assistant GUI is better for beginners than paper
and pencil. The mouse/screen/keyboard interface may even hinder,
at least initially, a student's development. The next major step in
proof-assistive technology will use handwriting recognition technology,
perhaps via a tablet PC equipped with
a stylus and appropriate software for emulation of a
blackboard. But even virtual reality software supporting an infinite
virtual blackboard cannot replace the ultimate tool -- a higly
motivated and well-educated mind. In the end, the value of this
software or any other software must be measured by the human
accomplishments it enables; if the software is helpful, fine,
otherwise, do not hesitate to rubbish it and find a new way!
Usage:
The Derive Feature requires no change to the format of the Proof
Assistant GUI proof text, just minor changes in the way the user's
input is validated and
interpreted. The new Derive Feature is tightly integrated into the
existing Unification process and is triggered in due course by user
input, as follows:
- Formula
Generation: Formula
is now an optional entry on derivation proof steps except for the '
qed
' (final) step (and remains
mandatory on hypothesis steps). Either Formula
or Ref must be entered on each
derivation proof step. In
the case where the Formula is not input, a Ref
label is required, and is used along with the input Hyp's to generate
a Formula. Variables that are not
completely determined by the input Ref
and Hyp(s) are shown as "&W1
", "&W2
", etc.
- Hypothesis
Generation: omitted
or "
?
" Hyp sub-field entries are used to
generate hypothesis proof steps only if a Ref
label is input and the total number of non-"?
" Hyp entries is less than the number
of hypotheses used by the Ref'd
assertion -- and no other errors are found. The process contains
a
tiny amount of built-in intelligence and works as follows:
unification
of the input Ref assertion
with the derivation step's Formula
and given (non-"?
") Hyp entries is attempted. If this
partial unification is successful, an hypothesis Formula is generated for each
omitted Hyp or "?
". Then, each generated Formula that is completely
determined (contains no Work Variables
), is compared to
the Formulas of the previous
proof steps. If a match is found, then the corresponding omitted or "?
" Hyp
is changed to the Step number
of the matching formula. Otherwise, if no matching Formula is found, or if the
generated Formula
contains un-determined variables, then a new derivation proof step is
created and inserted in the proof immediately prior to the current
derivation step, and the corresponding Hyp,
omitted or "?
" is updated to
reflect the inserted Step
number.
- Generated Step
numbers
are assigned sequentially by adding 1000 to the greatest Step number in the proof at that
moment. So, if the greatest Step
number in the proof = 5, then the generated hypothesis steps are
numbered 1005, 2005, ..., etc. Note:
for each generated hypothesis
inserted in the proof, the output Hyp
and Ref sub-fields are set to null and
Unification is attempted -- then, if Unification fails, the Hyp is set
to "?
".
Originally, the plan was to set Hyp
to "?
", which would
automatically prevent unification of the generated step. However, given
that in many cases the generated Formula
will be completely determined (with no Work Variables
variables) and would unify with an assertion requiring no logical
hypotheses!
Example 1: Using Derive as a typing short-cut.
Below is the output after File/New
Proof + "syl
".
Notice that syl
's hypothesis
steps are pre-loaded, as is the 'qed
'
derivation step. All we need to do is fill in the middle steps!
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=?
h1::syl.1 |- ( ph
-> ps )
h2::syl.2 |- ( ps
-> ch )
3::
|- ?
qed::
|- ( ph -> ch )
$)
We enter steps 3 and 4 as shown
below.
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=
h1::syl.1 |- ( ph -> ps )
h2::syl.2 |- ( ps -> ch )
3:2:a1i
4:3:a2i
qed:1,4 |- ( ph -> ch )
$)
and select the Unify/Unify (check proof) menu item
or press the Ctrl
and "U
" keys simultaneously. The
following is output.Notice that step 3's formula is completed but that
it contains a Work Variable, &W1
.
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=
h1::syl.1 |- ( ph -> ps )
h2::syl.2 |- ( ps -> ch )
3:2:a1i |- ( &W1 -> (
ps
-> ch ) )
4:3:a2i
qed:1,4 |- ( ph -> ch )
$)
The error message screen also
appeared, reporting unification
errors in steps 4 and 'qed
'
-- we ignore those errors for now...and change the "&W1
' in step 3 to "ph
". Then we select the Unify/Unify (check proof) menu item
or press the Ctrl
and "U
" keys simultaneously. The
following screen appears:
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=
h1::syl.1 |- ( ph -> ps )
h2::syl.2 |- ( ps -> ch )
3:2:a1i |- ( ph -> ( ps
-> ch ) )
4:3:a2i |- ( ( ph -> ps )
-> ( ph -> ch ) )
qed:: |- ( ph -> ch )
$)
The error message screen also
appears, showing the following message:
E-PA-0411
Theorem syl Step qed: Unification failure in derivation proof step. The
step's formula and/or its hypotheses could not be reconciled with an
Assertion (axiom or theorem) in the loaded Metamath file(s).
---------------------------------------------------------
The problem is that we need to
specify either a Ref, or Hyps, or both. To demonstrate
Derive's Hyp generation
feature, we enter "?
"
as Hyp for the 'qed
'
step and ax-mp
as
the Ref
, as shown below:
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=
h1::syl.1 |- ( ph -> ps )
h2::syl.2 |- ( ps -> ch )
3:2:a1i |- ( ph -> ( ps
-> ch ) )
4:3:a2i |- ( ( ph -> ps )
-> ( ph -> ch ) )
qed:?:ax-mp |- ( ph -> ch )
$)
Then we select the Unify/Unify (check proof) menu item
or press the Ctrl
and "U
" keys simultaneously. The
following screen appears:
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=
h1::syl.1 |- ( ph
-> ps )
h2::syl.2 |- ( ps
-> ch )
3:2:a1i
|- ( ph -> ( ps -> ch ) )
4:3:a2i
|- ( ( ph -> ps ) -> ( ph -> ch ) )
1004:?:
|- &W1
2004:?:
|- ( &W1 -> ( ph -> ch ) )
qed:1004,2004:ax-mp |- ( ph -> ch )
$)
Oh boy, still not done! Why!?!
Answer: specifying "?" as the Hyp for ax-mp provided incomplete
information.The missing information is represented with the Work
Variable, &W1
in steps
1004 and 2004, which were generated by the Proof
Assistant --- which unfortunately, is not smart enough to figure out
that it should have just taken steps 1 and 4 as the hypotheses for the
'qed' step. However,
it is now obvious how to complete the
proof: - we delete steps 1004
and 2004
, and input "1,4
" as the Hyp of the 'qed
' step as shown below:
$(
<MM> <PROOF_ASST> THEOREM=syl LOC_AFTER=?
h1::syl.1 |- ( ph
-> ps )
h2::syl.2 |- ( ps
-> ch )
3:2:a1i
|- ( ph -> ( ps -> ch ) )
4:3:a2i
|- ( ( ph -> ps ) -> ( ph -> ch ) )
qed:1,4:ax-mp |- ( ph -> ch )
$)
Then we select the Unify/Unify (check proof) menu item
or press the Ctrl
and "U
" keys simultaneously. The
following screen appears:
$( <MM> <PROOF_ASST>
THEOREM=syl LOC_AFTER=?
h1::syl.1 |- ( ph
-> ps )
h2::syl.2 |- ( ps
-> ch )
3:2:a1i
|- ( ph -> ( ps -> ch ) )
4:3:a2i
|- ( ( ph -> ps ) -> ( ph -> ch ) )
qed:1,4:ax-mp |- ( ph -> ch )
$= wph wps wi wph wch wi syl.1 wph wps wch wps wch wi wph syl.2
a1i a2i ax-mp
$.
$)
Bingo! Ka-ching!
Example 2: Using Derive to develop a proof by working
backwards from the conclusion to the hypotheses.
Below is the output after File/New
Proof + "dfuz
".
Notice that dfuz
's hypothesis
step is pre-loaded, as is the 'qed
'
derivation step. All we need to do is fill in the middle steps!
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=?
h1::dfuz.1 |- N e. ZZ
2::
|- ?
qed:: |- {
z e. ZZ | N <_ z } =
|^| { x | ( N e. x /\ A. y e. x ( y + 1 ) e. x ) }
$)
Ok, that looks simple
enough......the user inputs no Hyps
and "eqri" in the "qed"
step and deletes step 2, as shown below:
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=?
h1::dfuz.1 |- N e. ZZ
qed::eqriv |- { z e. ZZ | N <_ z
} =
|^| { x | ( N e. x /\ A. y e. x ( y + 1 ) e. x ) }
$)
He selects the Unify/Unify (check proof) menu item
or presses the Ctrl
and "U
" keys simultaneously. The
following screen appears:
$( <MM>
<PROOF_ASST> THEOREM=syl LOC_AFTER=?
h1::dfuz.1 |- N e. ZZ
1001:?:
|- ( &S1 e. { z e. ZZ | N <_ z } <-> &S1 e. |^| { x |
( N e.
x
/\ A. y e. x ( y + 1 ) e. x ) } )
qed:1001:eqriv |- { z e. ZZ | N <_ z } =
|^| { x | ( N e. x /\ A. y e. x ( y + 1 ) e. x ) }
$)
OK! A hard problem, deriving the
'qed' step, has been turned into an easy problem, deriving step 1001 --
which we leave as an exercise for the motivated reader. (Good luck!)
P.S. The following RunParm line inserted just before the
RunProofAsstGUI line will create a proof for dfuz that can be input
into the Proof Assistant using File/Open:
ProofAsstExportToFile,dfuz,dfuz.mmp,new,un-unified,NotRandomized,NoPrint
Options are new/
update
(the output proof
file), unified/un-unified
(the output proof), Randomized/NotRandomized
( proof step Hyp order), Print/NoPrint
(the output
proof).
This RunParm gives you something to play with and may be useful in
cloning proofs or finding shorter proofs.
See also:
Proof Assistant User Guide
ProofAssistantGUIQuickHOWTO.html
ProofAssistantGUIDetailedInfo.html
StepUnifier.html
WorkVariables.html
PageLocalRef.mmp