Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, your hol_light/Multivariate/geom.ml proofs are amazing, but too 
complicated for high school students, and I think we ought to give a nice 
formalization of coordinate geometry, especially as the new high school Common 
Core Geometry standards might mean doing coordinate geometry and getting rid of 
axiomatic proofs.  Here's a sketch for how to do this.  Part of it is much 
trickier than I would like, and maybe you can simplify this.

Let's prove your TRIANGLE_ANGLE_SUM by rigorizing the standard high school 
non-rigorous Euclid proof, which I gave a Hilbert formalization as 
TriangleSum : thm =
  |- ∀A B C. ¬Collinear A B C
 ⇒ μ (∡ A B C) + μ (∡ B C A) + μ (∡ C A B) = &180
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
(more recent than the version you graciously included in subversion 151) where 
I borrowed ideas from your geom.ml. Using my notation, we have 3 noncollinear 
points A, B & C.  We need a line through B parallel to AC with points E & F on 
it, and that's easy:

Let v = C - A (the direction vector of AC), and also let 
a = B - A and c = B - C.  Let 
E = B - v and 
F = B + v.
We easily get the 2 angle equalities, 
EBA = CAB and CBF = BCA, from your vector/acs definition of angle:

cos (CAB) = (v dot a) / (|v| |a|) = cos (EBA)
cos (BCA) = - (c dot v) / (|c| |v|) = cos (CBF)

We need to show something like what I write:
C is in the interior of ABF.  
That's really easy with your vectors, because we have a parallelogram ABFC, 
where the diagonals intersect at the midpoints

M = A + (1/2)(a + v) = (1/2)(B + C) = (1/2)(A + F)

ABM = ABC and MBF = CBF since M is the midpoint of B & C.  Since M is the 
midpoint of A & F, we have
between M (A,F).  
So far, this is much simpler than my Hilbert proof, because we didn't use any 
Hilbert betweenness stuff, needed e.g. for the converse of the Alternate 
Interior Angles Theorem.  And between M (A,F) implies, by your 
ANGLES_ADD_BETWEEN,

ABF = ABM + MBF = ABC + CBF.

That's the only hard part: giving a simple proof of ANGLES_ADD_BETWEEN.  Your 
proof uses TRIANGLE_ANGLE_SUM, which you prove with your amazing calculation 
cos(ABC + BCA + CAB) = -1.
Putting this off, we need supplementary angles to add up to pi,

EBA + ABF = pi.

You have a lot of results like that in geom.ml, e.g. ANGLES_ALONG_LINE, and I 
bet this isn't too hard, although I don't understand your proof yet.  Now we're 
done:

ABC + BCA + CAB = ABC + CBF + EBA = ABF + EBA = pi.

So we must give a simple proof of ANGLES_ADD_BETWEEN.  I'll state it like this: 
 Take 3 our noncollinear points to be O = (0, 0) and two points on the unit 
circle, A and B = (1, 0).  Let 
P = sA + (1 - s)B for some s in (0, 1).  Then ANGLES_ADD_BETWEEN says that 

angle(A,O,P) + angle(P,O,B) = angle(A,O,B).

We'll need to push P onto the unit circle, so let 
X = (1/|P|) P.
Then |X| = 1, and we're proving 

angle(A,O,X) + angle(X,O,B) = angle(A,O,B).

I want to define angle by arclength along the unit circle, which specializes to 
arc-cos defined by 

acs(x) = int_x^1 dt / sqrt{1 - t^2}

when, as in our case, B = (1,0).  Your definition of acs using complex 
logarithm is too advanced for high school, and maybe it won't work for what I 
want anyway.  That means we need a new proof of SIN_ADD and COS_ADD, and that's 
bound to be harder than your immediate proofs using the complex exponential 
function.  Well, a more geometric proof using vectors is OK, right?

So angle(A,O,B) = acs(A dot B),
angle(X,O,B) = acs(X dot B).  

That makes ANGLES_ADD_BETWEEN almost obvious, but we need a betweenness result 
on the unit circle.  This requires a result that I found surprisingly hard to 
prove.  My son read my proof and helped me spot a good number of mistakes.  I 
think it's fine now, but maybe someone knows a simpler proof.

Lemma:
A dot B < X dot B.

Proof:
Write d = A dot B.  |d| < 1 by the usual proof:

1 - d^2 = |A|^2 |B|^2 - d^2 = (a_1^2 + a_2^2)(b_1^2 + b_2^2) - (a_1 b_1 + a_2 
b_2)^2 
=
a_1^2 b_2^2 + a_2^2 b_1^2 - 2 a_1 b_1a_2 b_2 = (a_1 b_2 - a_2 b_1)^2 > 0 

because we're squaring the determinant, which is nonzero because A and B are 
linearly independent, since we assumed that A, O & B are non-collinear.  Thus 
|d| < 1.

So we're proving d < X dot B.  Recall 
P = sA + (1 - s)B.  Then 

|P|^2 = s^2 + 2s(1 - s) d + (1 - s)^2,
so
|P|^2 <  s^2 + 2s(1 - s) + (1 - s)^2 = (s + 1 - s)^2 = 1 

since d < 1.  Thus |P| < 1.  Since 

X dot B = (1/|P|) (s d + 1 - s),

we're proving 

|P| d < s d + 1 - s.

We have three cases. 

Suppose 0 <= d < 1.  We're proving 

(|P| - s) d < 1 - s, 
but 
(|P| - s) d <= (1 - s) d < 1 - s

since d >= 0 and 1 - s > 0. 
qed

Suppose d < 0 and s d + 1 - s >= 0.  Then

|P| d < 0 <= s d + 1 - s
qed

Suppose d < 0 and s d + 1 - s < 0.

Our result follows from the result of squaring both sides and changing the 
inequality 

(|P| d)^2 > (s d + 1 - s)^2

And that's 

(s^2 + 2 s (1 - s) d + (1 - s)^2) d^2 > s^2 d^2 + 2 s (1 - s) d + (1 - s)^

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, I'm now certain that your proof of TRIANGLE_ANGLE_SUM_LEMMA is pretty 
much what I posted yesterday.  I was confused about LAW_OF_COSINES, a vector 
triviality which I actually used.  Here's a better proof that my son & I worked 
out today.  Which is to say, I gave it to him as a guided exercise, and he came 
up with some simplifications I didn't expect.  I think this is a really nice 
proof, and one I was completely unaware of, and it's due to you and HOL Light.

Let A, B & C be non-collinear points in R^2, with angles α, β & γ next to the 
vertices respectively, and opposite sides a, b & c resp. Let u, v & w be the 
vectors 
u = C - B
v = A - C
w = C - B
Then w = u + v, |u| = a, |v| = b and |c| = |w|.   By LAW_OF_COSINES, 
c^2 = a^2 + b^2 + 2(u dot v) 
and this is just the vector triviality, the distributivity of the dot product 
over addition, 
c^2 = |w|^2 = w dot w = (u + v) dot (u + v) = |u|^2 + 2(u dot v) + |v|^2 
Then by ANGLE

cos α = (v dot w) / (bc), 
cos β = (u dot w) / (ac), 
cos γ = - (u dot v) / (ab),

since - v = C - A, and so 

cos α cos β cos γ = - (u dot v) (u dot w) (v dot w) / (a^2 b^2 c^2)  .

By LAW_OF_SINES and the above

cos α sin β sin γ = (v dot w) (b^2 c^2 - (v dot w)^2) / (a^2 b^2 c^2) 
cos β sin α sin γ = (u dot w) (a^2 c^2 - (u dot w)^2) / (a^2 b^2 c^2) 
cos γ sin α sin β  = - (u dot v) (a^2 b^2 - (u dot v)^2) / (a^2 b^2 c^2) 

By COS_ADD & SIN_ADD

cos(α + β + γ) = cos(α) cos(β + γ) - sin(α) sin(β + γ) 
=
cos α cos β cos γ - (cos α sin β sin γ + cos β sin α sin γ + cos γ sin α sin β)
so

a^2 b^2 c^2 cos(α + β + γ) 
= 
- (u dot v) (u dot w) (v dot w) + (u dot v) (a^2 b^2 - (u dot v)^2) - 
(v dot w) (b^2 c^2 - (v dot w)^2) - (u dot w) (a^2 c^2 - (u dot w)^2)

The plan is to eliminate w and c, by 
w = u + v,
c^2 = a^2 + b^2 + 2(u dot v).
It's easier to read if we write 
d = u dot v.
Then 
u dot w = a^2 + d
v dot w = b^2 + d
so

a^2 b^2 c^2 cos(α + β + γ) 
= 
- d (a^2 + d) (b^2 + d) + d (a^2 b^2 - d^2) - 
(b^2 + d) (b^2 c^2 - (b^2 + d)^2) - 
(a^2 + d) (a^2 c^2 - (a^2 + d)^2)

Now
a^2 c^2 - (a^2 + d)^2 
= 
a^2(a^2 + b^2 + 2d)  - (a^4 + 2a^d + d^2) = a^2 b^2 - d^2

similarly b^2 c^2 - (b^2 + d)^2 = a^2 b^2 - d^2 

Factoring the common a^2 b^2 - d^2  and using 
c^2 = b^2 + a^2 + 2d, we have 

a^2 b^2 c^2 cos(α + β + γ) 
= 
- d (a^2 + d) (b^2 + d) + d (a^2 b^2 - d^2) - c^2 (a^2 b^2 - d^2)
= 
- a^2 b^2c^2 - d^2(a^2 + b^2) - 2d^3 + c^2 d^2
=
- a^2 b^2c^2 - d^2(a^2 + b^2 + 2d - c^2) = - a^2 b^2c^2

Thus 
cos(α + β + γ) = -1.

That's an amazing proof, John!  Thanks for teaching it to me, through HOL 
Light!  

Now back to possible secret Hilbert betweenness.  It would be no trouble to 
prove all the Hilbert betweenness in coordinate geometry, and you prove some 
later in e.g. ANGLES_ADD_BETWEEN, but I am curious.  You defined e^z, sin(x), 
cos(x) by power series and therefore proved COS_ADD & SIN_ADD.  ANGLE follows 
from the definition of angles, i.e. vector_angle which uses acs, arc-cos.  So 
it's all Calculus so far, and that's great.  The LAW_OF_COSINES is just vector 
properties, so all that's left, I think, is LAW_OF_SINES, which actually sounds 
geometric, and has a long interesting looking proof. 

-- 
Best,
Bill 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, I'm finally responding to your Aug 31 post.  I lifted a bold, clever 
proof of TRIANGLE_ANGLE_SUM in Multivariate/geom.ml, although your actual proof 
may be simpler.  I ran your code below, and saw the goalstacks, but they didn't 
help much, because it's really TRIANGLE_ANGLE_SUM_LEMMA I want.  Below I'll 
discuss the proof of that:

   Even if you don't learn how to write procedural proofs, it wouldn't
   be too hard for you to step through existing ones
   step-by-step. [...] You can see the sequence of goals that gets
   generated.

 needs "Multivariate/geom.ml";;

 g `!A B C:real^N. ~(A = B /\ B = C /\ A = C)
   ==> angle(B,A,C) + angle(A,B,C) + angle(B,C,A) = pi`;;

 e(REPEAT GEN_TAC THEN MAP_EVERY ASM_CASES_TAC
[`A:real^N = B`; `B:real^N = C`; `A:real^N = C`] THEN
   ASM_SIMP_TAC[ANGLE_REFL_MID; ANGLE_REFL; REAL_HALF; REAL_ADD_RID] THEN
   REPEAT(FIRST_X_ASSUM SUBST_ALL_TAC) THEN
   REPEAT(POP_ASSUM MP_TAC) THEN REWRITE_TAC[REAL_ADD_LID; REAL_HALF]);;

 e(REPEAT STRIP_TAC THEN MATCH_MP_TAC COS_MINUS1_LEMMA);;

 e(ASM_SIMP_TAC[TRIANGLE_ANGLE_SUM_LEMMA; REAL_LE_ADD; ANGLE_RANGE]);;

 e(MATCH_MP_TAC(REAL_ARITH
`&0 <= x /\ x <= p /\ &0 <= y /\ y <= p /\ &0 <= z /\ z <= p /\
 ~(x = p /\ y = p /\ z = p)
 ==> x + y + z < &3 * p`));;

 e(ASM_SIMP_TAC[ANGLE_RANGE] THEN REPEAT STRIP_TAC);;

 e(REPEAT(FIRST_X_ASSUM(MP_TAC o GEN_REWRITE_RULE I [ANGLE_EQ_PI_DIST])));;

 e(REPEAT(FIRST_X_ASSUM(MP_TAC o GEN_REWRITE_RULE RAND_CONV
[GSYM VECTOR_SUB_EQ])));;

 e(REWRITE_TAC[GSYM NORM_EQ_0; dist; NORM_SUB] THEN REAL_ARITH_TAC);;

I worked out a proof using the theorems you cited in the proof of 
TRIANGLE_ANGLE_SUM_LEMMA, but it occured to me afterwards that this may be 
quite different from your proof.  Anyway, I was shocked that this worked: 

Let a, b & c be the three angles of a triangle.  We want a + b + c = pi, and 
that will follow from 
cos(a + b + c) = - 1
I never would have tried to prove that, but using these results 

COS_ADD : thm = |- !x y. cos (x + y) = cos x * cos y - sin x * sin y
SIN_ADD : thm = |- !x y. sin (x + y) = sin x * cos y + cos x * sin y

from transcendentals.ml, we have 

cos(a + b + c) = cos(a) * cos(b + c) - sin(a) * sin(b + c) 
=
cos(a) * cos(b) * cos(c) - 
(cos(a) * sin(b) * sin(c) + sin(a) * cos(b) * sin(c) + sin(a) * sin(b) * cos(c))

Let x, y & z be the opposite sides of the angles a, b & c.  Then by 
LAW_OF_SINES,

sin(b) = y * sin(a) / x
sin(c) = z * sin(a) / x

cos(a) * sin(b) * sin(c) + sin(a) * cos(b) * sin(c) + sin(a) * sin(b) * cos(c)
=
sin^2(a) * (cos(a) * y * z / x^2 + cos(b) * z / x + cos(c) * y / x)

Now by SIN_CIRCLE

cos(a + b + c) = cos(a) * cos(b) * cos(c) - 
(1 - cos^2(a)) / x^2 * (cos(a) * y * z + cos(b) * x * z + cos(c) * x * y)

Now we have a shot, because we only have cosines, and we can use vector 
definition of angles, 
ANGLE : thm =
  |- !A B C.
 (A - C) dot (B - C) = dist (A,C) * dist (B,C) * cos (angle (A,C,B))

Let's say the points are A, B and C next to the angles a, b and c.  Then

cos(a) = (B - A) dot (C - A)  / (y * z)
cos(b) = (A - B) dot (C - B) / (x * z)
cos(c) = (B - C) dot (A - C) / (x * y)

1 - cos^2(a) = (y^2 * z^2 - ((B - A) dot (C - A))^2) / (y^2 * z^2)
cos(a) * y * z = (B - A) dot (C - A)
cos(b) * x * z = (A - B) dot (C - B)
cos(c) * x * y = (B - C) dot (A - C)

(x^2 * y^2 * z^2) * cos(a + b + c) 
= 
(B - A) dot (C - A) * (A - B) dot (C - B) * (B - C) dot (A - C) - 
(y^2 * z^2 - ((B - A) dot (C - A))^2) *
((B - A) dot (C - A) + (A - B) dot (C - B) + (B - C) dot (A - C))

By translating, we can make the simplification A = 0.  Call d = B dot C.  Then 
B dot B = z^2
C dot C = y^2
x^2 = (C - B) dot (C - B) = y^2 + z^2 - 2 * d 
Then we have 

(x^2 * y^2 * z^2) * cos(a + b + c) 
= 
d * (z^2 - d) * (y^2 - d)  - (y^2 * z^2 - d^2) * (d + z^2 - d + y^2 - d)
=
d * (z^2 - d) * (y^2 - d)  + (d^2 - y^2 * z^2) * (y^2 + z^2 - d)
=
 - y^2 * z^2 * (y^2 + z^2) + d * 2 * y^2 * z^2 
=
- y^2 * z^2 * (y^2 + z^2 - 2 * d) = - y^2 * z^2 * x^2.

Thus cos(a + b + c) = -1, and this proves your TRIANGLE_ANGLE_SUM!!!  I tried 
your g & e stunts on TRIANGLE_ANGLE_SUM

 g `!A B C:real^N. ~(A = B) /\ ~(A = C) /\ ~(B = C)
  ==> cos(angle(B,A,C) + angle(A,B,C) + angle(B,C,A)) = -- &1`;;

val it : goalstack = 1 subgoal (1 total)

`!A B C.
 ~(A = B) /\ ~(A = C) /\ ~(B = C)
 ==> cos (angle (B,A,C) + angle (A,B,C) + angle (B,C,A)) = -- &1`

e(REPEAT GEN_TAC THEN ONCE_REWRITE_TAC[GSYM VECTOR_SUB_EQ] THEN
  REWRITE_TAC[GSYM NORM_EQ_0] THEN
  MP_TAC(ISPECL [`A:real^N`; `B:real^N`; `C:real^N`] LAW_OF_COSINES) THEN
  MP_TAC(ISPECL [`B:real^N`; `A:real^N`; `C:real^N`] LAW_OF_COSINES) THEN
  MP_TAC(ISPECL [`C:real^N`; `B:real^N`; `A:real^N`] LAW_OF_COSINES) THEN
  MP_TAC(ISPECL [`A:real^N`; `B:real^N`; `C:real^N`] LAW_OF_SINES) THEN
  MP_TAC(ISPECL [`B:real^N`; `A:real^N`; `C:real^N`] LAW_OF_SINES) THEN
  MP_TAC(ISPECL [`B:real^N`; `C:real^N`;

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Ramana Kumar]

On Tue, Sep 4, 2012 at 5:54 AM, Bill Richter
wrote:

> Thanks for correcting my typed LC, Ramana: no Y combinator (that makes
> sense, as Y sorta comes from Russell's paradox, which typing was designed
> to prevent), and it's "simply typed LC".  My "heavy" was just slang, and
> "generated" is from Hales's Notices article.  Maybe I wasn't clear about
> syntax and semantics, so I'll try again.  Let me first disagree with your
> comparison between FOL & HOL, in my case where FOL means ZC/FOL:
> (semantics)  | (semantics)
> domain   | type
> interpretation   | definition of constants
> I say the semantics for both is mostly a model of ZC, i.e. a huge
> collection of sets, as the HOL Logic manual explains at the very beginning.
>   I want to reserve the word type to mean syntax as you wrote yourself:
> (typed) variables.  Then the semantics must interpret the syntax (including
> types) in terms of sets.
>
> Types are not sets!  That's what I didn't understand.  ind->bool is a
> type, and terms can have this type, but ind->bool is not a set.  The
> semantic function M take this type to a set, quite likely the power set of
> the natural numbers P(N), which is more or less the set of real numbers R.
>   You this distinction on p 15 of the Logic manual:
>
>The terms of the HOL logic are expressions that denote elements of
>the sets denoted by types.
>
> So P(N) is the set denoted by the type ind->bool, and if the variable x
> has type ind->bool, the semantic function maps x to an element of the set
> P(N).  Surely the HOL experts know this (obvious Michael & Konrad do), and
> I can understand the experts blurring the distinction between syntax and
> semantics in an effort to explain HOL, but it's this blurring will I think
> be very confusing to mathematicians trying to understand HOL in terms of
> what they learned from e.g. Enderton's Mathematical Logic.  It certainly
> confused me, but I'm fine now.
>
> HOL and a ZC/FOL proof assistant both construct syntactic proofs.  We need
> semantics in order for these syntactic proofs to "mean" anything.  To prove
> theorems about actual sets, we take a semantic function like M of the Logic
> manual and apply it to our HOL syntactic proofs.  But we're not required to
> use the semantic function M of the Logic manual.  If we come up with a
> different semantic function, that's fine too.  The theorems that HOL proves
> for us will then have a (very slightly I'm bet) different meaning.
>
>An important things I think missing from your analogy (or
>comparison), though, is the definition of types and constants.
>
> I don't understand the question.  You know more than I do about types &
> constants in HOL than I do, and I think these don't exist in FOL.  I tried
> to explain that much of the ZC/FOL axioms (power set, products...) are
> encoded in the HOL type system (->, prod/#).
>

Constants do exist in FOL: they are called function/relation and predicate
symbols. In ZC/FOL you have constants like set-membership and equality
(both relations). But you can be more or less formal about how you define
new constants. In HOL, since we actually define things like the logical
connectives and quantifiers (and,or,not,forall,etc.) rather than having
them built into the syntax, we have principles of definition.


>
>The property of product types you wrote above is guaranteed by the
>definition of product types. It is not part of the logical
>foundation, but rather is carefully ensured by JRH or whoever wrote
>the theory of pairs as definitions of new types and constants above
>the basic logical foundation.
>
> Ah, so I wouldn't have found it in the Logic manual.  Thanks.  Can you
> tell me where HOL4 defines the product type `prod'?  John certainly
> explains how to use his product type # and pairs.
>

In HOL4 it's src/pair/src/pairScript.sml
In HOL Light it's pair.ml.
Logically, the definition of the product type in both systems is the same:
do you understand what prod_tybij is doing in the HOL Light pair.ml script?


>
>>  but HOL could easily be explained without this cool typed LC.
>
>Certainly you don't have to mention "lambda calculus", but you're
>going to have to describe something isomorphic to it in explaining
>what the terms of your proof system are.
>
> No, LC is a deep theory which e.g. explains how to define the logical
> operators and, not, forall, exists, implies etc, which Enderton would take
> to be fundamental notions.  One kind of term is a lambda abstraction, which
> use the symbol lambda (λ or \).  But that's not a serious use of LC.
>
> --
> Best,
> Bill
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http:/

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks for correcting my typed LC, Ramana: no Y combinator (that makes sense, 
as Y sorta comes from Russell's paradox, which typing was designed to prevent), 
and it's "simply typed LC".  My "heavy" was just slang, and "generated" is from 
Hales's Notices article.  Maybe I wasn't clear about syntax and semantics, so 
I'll try again.  Let me first disagree with your comparison between FOL & HOL, 
in my case where FOL means ZC/FOL:
(semantics)  | (semantics)
domain   | type
interpretation   | definition of constants
I say the semantics for both is mostly a model of ZC, i.e. a huge collection of 
sets, as the HOL Logic manual explains at the very beginning.   I want to 
reserve the word type to mean syntax as you wrote yourself: (typed) variables.  
Then the semantics must interpret the syntax (including types) in terms of 
sets.  

Types are not sets!  That's what I didn't understand.  ind->bool is a type, and 
terms can have this type, but ind->bool is not a set.  The semantic function M 
take this type to a set, quite likely the power set of the natural numbers 
P(N), which is more or less the set of real numbers R.   You this distinction 
on p 15 of the Logic manual: 

   The terms of the HOL logic are expressions that denote elements of
   the sets denoted by types.

So P(N) is the set denoted by the type ind->bool, and if the variable x has 
type ind->bool, the semantic function maps x to an element of the set P(N).  
Surely the HOL experts know this (obvious Michael & Konrad do), and I can 
understand the experts blurring the distinction between syntax and semantics in 
an effort to explain HOL, but it's this blurring will I think be very confusing 
to mathematicians trying to understand HOL in terms of what they learned from 
e.g. Enderton's Mathematical Logic.  It certainly confused me, but I'm fine 
now.  

HOL and a ZC/FOL proof assistant both construct syntactic proofs.  We need 
semantics in order for these syntactic proofs to "mean" anything.  To prove 
theorems about actual sets, we take a semantic function like M of the Logic 
manual and apply it to our HOL syntactic proofs.  But we're not required to use 
the semantic function M of the Logic manual.  If we come up with a different 
semantic function, that's fine too.  The theorems that HOL proves for us will 
then have a (very slightly I'm bet) different meaning.  

   An important things I think missing from your analogy (or
   comparison), though, is the definition of types and constants.

I don't understand the question.  You know more than I do about types & 
constants in HOL than I do, and I think these don't exist in FOL.  I tried to 
explain that much of the ZC/FOL axioms (power set, products...) are encoded in 
the HOL type system (->, prod/#).

   The property of product types you wrote above is guaranteed by the
   definition of product types. It is not part of the logical
   foundation, but rather is carefully ensured by JRH or whoever wrote
   the theory of pairs as definitions of new types and constants above
   the basic logical foundation.

Ah, so I wouldn't have found it in the Logic manual.  Thanks.  Can you tell me 
where HOL4 defines the product type `prod'?  John certainly explains how to use 
his product type # and pairs.  

   >  but HOL could easily be explained without this cool typed LC.

   Certainly you don't have to mention "lambda calculus", but you're
   going to have to describe something isomorphic to it in explaining
   what the terms of your proof system are.

No, LC is a deep theory which e.g. explains how to define the logical operators 
and, not, forall, exists, implies etc, which Enderton would take to be 
fundamental notions.  One kind of term is a lambda abstraction, which use the 
symbol lambda (λ or \).  But that's not a serious use of LC.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Ramana Kumar]

On Mon, Sep 3, 2012 at 6:36 AM, Bill Richter
wrote:
>
> I think I finally understand the relationship between HOL and ZFC/FOL,
> after thinking about p 5 of Tom Hales's Notices article
> www.ams.org/notices/200811/tx081101370p.pdf, at least in the monomorphic
> case.  It will take me a while to get the details straight, and I hope
> folks here (Michael & Konrad especially) will help me straighten this out.
>  I think to bring mathematicians into the formal proofs revolution, some
> documentation like this is needed.  So:
>
> Math folks more or less understand ZFC/FOL: ∀, ∃, ¬, ∧, ∨, ⇒,⇔, axioms,
> rules of inference, syntactic proofs we can check on the computer, the f.o.
> ZFC axioms.  A model of ZFC is a big enough collection of sets, but you
> don't need a model to check syntactic ZFC proofs on the computer. HOL must
> have a similar description!  And it goes like this, I think:
>
> HOL can be understood completely as syntax.


There is a syntactic side of the story and a semantic side, just as with
FOL.


>  All variables have a type, and the types are generated by the type
> constants bool, ind and ->,


New types can be defined, as you say below: not all of them are generated
by bool, ind, and -> (depending on what you mean by "generated").


> as Tom writes, but we surely need a compound type for products as well,
> the prod/# of HOL4/HOL-Light.  We can also define our own type constants
> (John defined point, Between and === for me).
>
> HOL involves heavy typed LC (partly explained in Chris Hankin's yellow
> book Lambda Calculi), because all variables are typed, and also because we
> can define ∀, ∃, ¬, ∧, ∨, ⇒ and ⇔ in LC.


Not sure what you mean by "heavy typed". HOL is "simply typed lambda
calculus", and that is a standard term.


>  We can also define recursive functions in LC with the Y combinator.


The Y combinator doesn't work in simply typed calculus (it is untypeable).
Support for recursive functions is developed differently (using recursive
types).


> The rules of inference are quite simple, and hover around the LC alpha and
> beta reduction,


alpha reduction is usually built into the syntax (it is invisible to the
inference rules). beta reduction is an inference rule, though.


> and the more complicated inference rules are then given by LC.  That's all
> very elegant, and I can understand why CS folks would do it, as LC was the
> first programming language, but HOL could easily be explained without this
> cool typed LC.


I'm not sure that it could. Certainly you don't have to mention "lambda
calculus", but you're going to have to describe something isomorphic to it
in explaining what the terms of your proof system are.


>
> The ZFC axioms (or as Rob corrects me, the ZC axioms) are partly encoded
> in the type system (e.g. -> looks like the ZC power set axiom) but also in
> that a subset of a type is defined by a function/expression (another ZC
> axiom) written as a lambda abstraction.  We can add in our own axioms with
> new_axiom.
>
> That's the syntactic description of (monomorphic) HOL, which seems quite
> analogous to ZC/FOL.  Now we turn to semantics, which the HOL4 manual
> begins with: take a huge set of sets U, the types are mapped to sets in U
> in a simple way (in the monomorphic case), so type A -> B is mapped to the
> function space X -> Y, where the sets X & Y are the elements in U which A &
> B map to, and an abstraction is sent to the subset of it's type, the subset
> guaranteed by the ZC axioms.  So the semantics of HOL look very similar to
> the ZC semantics.  The main difference I see is that ZC has the bottom
> (emptyset) but not the top (U), vice versa for HOL.
>
> Isn't that a simple analogy between HOL and ZC/FOL?  My guess is most
> folks here understand this quite well.  I don't know where this simple
> analogy is documented.  I'm very happy to finally understand it.


Here is my attempt at an analogy. Does it match up with yours? I'm not sure.

FOL  | HOL
(syntax) | (syntax)
variables| (typed) variables
terms| (simply typed) terms
function symbol  | constant with function type
predicate symbol | constant with type whose range is bool
formulas | terms of type bool
(semantics)  | (semantics)
domain   | type
interpretation   | definition of constants

Hmm this is turning more into an embedding of FOL into HOL... I'm not sure
how strong the analogy really is...
An important things I think missing from your analogy (or comparison),
though, is the definition of types and constants. In FOL do you just use
abbreviations, or is there a notion of definition that is logically visible?


>
> There are a number of holes in my understanding.  Here's a very simple
> matter I don't understand:
> On p 15 of the HOL4 Logic manual, an application is written as
> (t_{s1->s2} t'_{s1})_{s2}
> That is, in order to form the application t t', there must exist types s1
> and s2 such that t has type s1->s2 and t' has type 

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

I think I finally understand the relationship between HOL and ZFC/FOL, after 
thinking about p 5 of Tom Hales's Notices article 
www.ams.org/notices/200811/tx081101370p.pdf, at least in the monomorphic case.  
It will take me a while to get the details straight, and I hope folks here 
(Michael & Konrad especially) will help me straighten this out.  I think to 
bring mathematicians into the formal proofs revolution, some documentation like 
this is needed.  So:

Math folks more or less understand ZFC/FOL: ∀, ∃, ¬, ∧, ∨, ⇒,⇔, axioms, rules 
of inference, syntactic proofs we can check on the computer, the f.o. ZFC 
axioms.  A model of ZFC is a big enough collection of sets, but you don't need 
a model to check syntactic ZFC proofs on the computer. HOL must have a similar 
description!  And it goes like this, I think:

HOL can be understood completely as syntax.  All variables have a type, and the 
types are generated by the type constants bool, ind and ->, as Tom writes, but 
we surely need a compound type for products as well, the prod/# of 
HOL4/HOL-Light.  We can also define our own type constants (John defined point, 
Between and === for me).

HOL involves heavy typed LC (partly explained in Chris Hankin's yellow book 
Lambda Calculi), because all variables are typed, and also because we can 
define ∀, ∃, ¬, ∧, ∨, ⇒ and ⇔ in LC.  We can also define recursive functions in 
LC with the Y combinator.  The rules of inference are quite simple, and hover 
around the LC alpha and beta reduction, and the more complicated inference 
rules are then given by LC.  That's all very elegant, and I can understand why 
CS folks would do it, as LC was the first programming language, but HOL could 
easily be explained without this cool typed LC.

The ZFC axioms (or as Rob corrects me, the ZC axioms) are partly encoded in the 
type system (e.g. -> looks like the ZC power set axiom) but also in that a 
subset of a type is defined by a function/expression (another ZC axiom) written 
as a lambda abstraction.  We can add in our own axioms with new_axiom. 

That's the syntactic description of (monomorphic) HOL, which seems quite 
analogous to ZC/FOL.  Now we turn to semantics, which the HOL4 manual begins 
with: take a huge set of sets U, the types are mapped to sets in U in a simple 
way (in the monomorphic case), so type A -> B is mapped to the function space X 
-> Y, where the sets X & Y are the elements in U which A & B map to, and an 
abstraction is sent to the subset of it's type, the subset guaranteed by the ZC 
axioms.  So the semantics of HOL look very similar to the ZC semantics.  The 
main difference I see is that ZC has the bottom (emptyset) but not the top (U), 
vice versa for HOL.

Isn't that a simple analogy between HOL and ZC/FOL?  My guess is most folks 
here understand this quite well.  I don't know where this simple analogy is 
documented.  I'm very happy to finally understand it.

There are a number of holes in my understanding.  Here's a very simple matter I 
don't understand: 
On p 15 of the HOL4 Logic manual, an application is written as 
(t_{s1->s2} t'_{s1})_{s2}
That is, in order to form the application t t', there must exist types s1 and 
s2 such that t has type s1->s2 and t' has type s1. Then t t' has type s2.  
That's of course what we'd want, and something like that must be true 
generally, e.g. for products, so (using the HOL Light convention), it must true 
that if x has type t#t', then there must exist unique y and z of type t and t' 
resp so that x = (y, z).  I know this is true because I do it in HOL Light, but 
I don't know where it's written down, or the various generalizations.  I'm sure 
it's well explained in the HOL4 manual, and I'll find it. 

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Konrad!  Are you and Michael interested in adding more introductory 
material to your HOL4 Logic manual, e.g. along the lines of the excellent intro 
material Michael just posted?  If so, I might have useful feedback.  Or do you 
want to keep your manual in its present form?  When I hit your link 
http://www.cl.cam.ac.uk/ftp/hvg/papers/HOLPaper.ps.gz 
I only get p 26, the end of the bib.  I tried reading the hol88 docs that John 
recommended, and I'm not sure I found the right stuff (just outline.dvi & 
paper.dvi), but it seemed short.  Would you compare the Logic manual to the 
hol88 docs?

Here's a dumb HOL question.  I keep failing to find where someone says, "In HOL 
we can do most of the set theory  mathematicians generally do".   And maybe I'm 
all wrong!  Maybe HOL is a different way to formalize math not primarily based 
on set theory!  Thierry Coquand's article Cris found for me 
http://plato.stanford.edu/entries/type-theory/

   How can we explain the notion of sets in term of types? There is an
   elegant solution, due to A. Miquel, which complements previous
   works by P. Aczel (1978) and which has also the advantage of
   explaining non necessarily well-founded sets a la Finsler. One
   simply interprets a set as a pointed graph (where the arrow in the
   graph represents the membership relation). [...]

I couldn't follow it, but I know your Logic manual doesn't mention either 
Miquel or Aczel, and I'm guessing that what Thierry is talking about here isn't 
central to HOL.

   Or are you just saying that you wish MESON proved more things more
   quickly? (In which case, why not use the prover9 interface, which I
   think HOL-Light provides. Maybe you'll get lucky!)

That's a good idea, prover9, which I haven't figured out, but I think prover9 
is more like Vampire than miz3.  It would be great to use prover9 to further 
Josef's experiment, see how many of my geometry proof prover9 can prove in one 
line.  

It's miz3 than I want to be faster, and MESON does most of the work, I think, 
of miz3.  If you would download my code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
run it, look at the proofs, I think you'll be surprised at how long the proofs 
take to run compared to how obvious the inferences I'm making are.  I have 67 
6-digit MESON "solved at" numbers.  You might enjoy reading my proofs anyway!  
John & Michael seemed to say that I'm having equational reasoning problems, not 
to be fixed by improving MESON.  

A different question: why can't one code up declarative proofs like mine in 
HOL4?  I think John thinks it isn't hard to do a bare-bones job, and perhaps 
even did that in his purple book.  Miz3 is an accomplishment primarily, I 
think, because of the caching that Freek wrote (so the 2nd time the proof goes 
MUCH faster) and because you can mix declarative & procedural proof styles.  
Plus miz3 held up very well under my torture-testing.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Cris,

| To what document is Bill referring here as Michael's "Logic manual"?

If you go to the HOL4 documentation page, there are links to several 
manuals, one of which is the "Logic" one:

  http://hol.sourceforge.net/documentation.html

As the introduction to that manual makes clear, the detailed
discussion of the logic has not changed much, if at all, since older
editions of the documentation dating back to HOL88. You can, for
example, find the older manuals in Camm Maguire's debian package
hol88-doc, which installs them in /usr/share/doc/hol88-doc
as gzipped dvi files.

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Cris Perdue]

Bill or Michael in particular, one question:

On Thu, Aug 30, 2012 at 7:39 PM, Bill Richter  wrote:

> Thanks for the HOL lesson, Michael, and clarifying about theorem-proving!
>  Can you give me some advice on how to read your 45 page Logic manual?  I
> need to understand why
>
>x : point [means]
>"x is an element of the set point"  (the reading we can derive using
> the semantics)
>
> Your Logic manual looks perfectly rigorous but it has real exposition
> problems for mathematicians like me.  Once I understand it, I'll try to
> make some suggestions on how to improve the exposition.  Perhaps it's
> written for people who already know everything that I'm struggling with.
>

To what document is Bill referring here as Michael's "Logic manual"?

Thanks in advance,
Cris


>
>Who wouldn't rather be doing deep stuff?
>
> I'd be happy to work on software verification, even it's "tedious in the
> computer, and unimaginably tedious with pen and paper".  Right now I don't
> have the skill, and my next step is to learn procedural proofs.  Let's try
> to settle this miz3 biz, and my first step is:
>
> Josef, my conjecture was wrong, and I regret my disparaging remarks about
> Mizar monkeying around with timeout numbers.  Piotr Rudnickii's article
> Obvious Inferences explains very interesting and sensible FOL, and his
> Herbrand stuff is discussed in John's book.  But my larger points (or
> Michael's) still hold, as Piotr explains:
>
> PR> In defining the class of obvious inferences there is a danger of
> PR> introducing a discrepancy between the user's sense of an obvious
> PR> inference and what the proof-checker is able to accept.
>
> Right, no FOL can't define what humans mean by obvious, so if Mizar's
> Herbrand obvious inference stuff actually captures our meaning of obvious,
> we're hitting Michael's sweet spot, and thinking Mizar always captures
> obvious our meaning of obvious is an illusion.
>
> PR> Firstly, the goal is to force students to write proofs in detail,
> PR> thus not all correct inferences have to be accepted.
>
> I am against this goal, and John has several times posted it is not his
> goal, most strongly today:
>
> JH> Generally speaking, I'd say that "the automation is too powerful"
> JH> is a problem we'd love [miz3] to have!
>
> Michael, the issue with Freek and miz3 is whether Freek intended to force
> students to write proofs in detail by setting timeout = 1 in miz3.  I
> believe (not sure) that he said that was not his intention.  What we know
> for sure is that Freek
> 1) often explains that one should set the timeout higher, even to -1 (no
> timeout)
> 2) explained the reason for timeout = 1: to limit user frustration when
> miz3 is trying very hard to prove something that's obviously wrong.  By
> setting timeout = 1, you get immediate feedback.
> What I said, and Freek didn't necessarily agree with, is that this
> immediate feedback is particularly important for new users, and I feel
> quite comfortable with timeout = 50.  I think Freek still often uses
> timeout = 1 for immediate feedback.
> All this makes for a good comparison between Freek and Heineken, which
> installs beer bottle tops to prevent stores and consumers from spilling the
> beer, not to force users to drink less.
>
>And really, why do we care?
>
> That's easy!  I want a smart HOL guy like you to think about how we can
> make miz3 (holby, actually) more powerful.  I'm having a bad interaction, I
> hazily conjecture, between the FOL that MESON is good at and the set theory
> in my paper.  For that, you must understand that intentional weakness isn't
> a miz3 goal, for then you efforts would be wasted.
>
> --
> Best,
> Bill
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Konrad Slind]

>
>Generally speaking, I'd say that "the automation is too powerful"
>is a problem we'd love [miz3] to have!
>
> Great!  Right now it's not powerful enough for me.

Bill, I'm struggling to understand your point of view. Of course,
more automation is a good thing, but presumably in your setting
full automation is not achievable, either on the grounds of
undecidability of the theory you are working in, or very high
computational complexity.  So maybe you are saying: "there
should be an algorithm, or heuristic, that efficiently proves all
statements that are obvious (to me)". That was the
approach of the early pioneers in automated proof, but resolution
theorem proving swept that notion aside, and I am not sure on what
scientific basis that could be revived. (Since "obvious" is a nebulous
conceptual blob of an idea.)

Or are you just saying that you wish
MESON proved more things more quickly? (In which case, why not
use the prover9 interface, which I think HOL-Light provides. Maybe you'll
get lucky!)

>The description of HOL in the Logic manual is based on a formal
>semantics inside set theory, developed by Andy Pitts.
>
> I see Andy wrote a paper with your advisor The HOL Logic and System but I 
> can't find a pdf for it.

 http://www.cl.cam.ac.uk/ftp/hvg/papers/HOLPaper.ps.gz

The first part, at least, provides something like what you seem to be
looking for.


Konrad.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Michael, that's extremely helpful, I need to read the part about 

  [p 17] The meaning of HOL terms in such a model will now be described.

and terms means constants as well as abstractions.  I should be able to decode 
your simple picture from the general description there. Page 19 more 
formidable.  BTW I'm familiar with the notation [[...]] from Denotational 
Semantic (DS) for Scheme e.g.  Do you see any connection between HOL semantics 
and DS?

What's bugging me a good deal more the ZFC connection, how do we pick up all 
the sets we need from such a small number of type operators and constants?  I 
only know of bool, ind & ->, and I can throw in point now.  I know that your 
universe U is, very crudely, a ZFC model, your semantic function M take type 
stuff to operators on U, and as you're telling me, to actual elements of U.  
I'm sure I'm missing something really obvious.

   My theory would be that the problem is that MESON is bad at equational 
   reasoning.  All you need to do (easy for me to say, of course) is to 
   occasionally use rewriting as well as MESON.

Thanks, and I think that's what John meant by 
"using a logical equivalence |- !x. P[x] <=> Q[x] to "rewrite" P to Q
inside another formula".  I'm over 100,000 in MESON calculations routinely, and 
I'm not sure I want to add REWRITE_TAC to every offending line.  I suppose 
there are more sophisticated rewriting tactics as well...

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 31/08/12 12:39, Bill Richter wrote:
> Thanks for the HOL lesson, Michael, and clarifying about theorem-proving!
> Can you give me some advice on how to read your 45 page Logic manual?  I need
> to understand why

>> x : point [means] "x is an element of the set point"  (the reading we can
>> derive using the semantics)

On page 17, the language

   "...if the term involves $m$ free variables..., then it is interpreted as a 
function $Y_1 \times \cdots \times Y_m \to Y$ where the sets $Y_1$,\dots,$Y_m$ 
are the interpretations of the types of the free variables in the term and the 
set $Y$ is the interpretation of the type of the term."

In the case of a single variable, $m=1$ and $Y_1 = Y$ because the type of the 
variable is the type of the whole term.

This language is saying that the interpretation of the bare variable $x$ is a 
function from Y to Y.  The domain of this function is all the possible values 
that $x$ might take on, and the result is the value of the whole term.  Clearly 
then the function in this case will be the identity.

This is the story in the absence of type variables.  If you further assume you 
are working only with closed terms where there are no free variables, the 
denotation will be a function from an empty vector of sets into the set denoted 
by the term's type (see midway through p19).  In this way we see that a closed 
term t of type σ denotes precisely one element in the set denoted by σ.

If you were dealing with closed terms only and terms with no type variables, 
then the semantics would be completely obvious:
- type constants map to non-empty sets
- type-operators like "list" map type-arguments to other types
- the function operator maps two sets to the total-function-space set over the 
two arguments
- term constants map to elements of their type (which may be a function space 
of 
course)
- applications map to the result of applying the corresponding function to the 
corresponding argument

This is the naive way of thinking about HOL that John referred to.

When you deal with free variables, as you have to when giving a meaning to 
abstractions, things start getting more complicated, though very much "in the 
way you'd expect".  Likewise dealing with type variables.

>> And really, why do we care?

> That's easy! I want a smart HOL guy like you to think about how we
> can make miz3 (holby, actually) more powerful. I'm having a bad
> interaction, I hazily conjecture, between the FOL that MESON is good
> at and the set theory in my paper. For that, you must understand
> that intentional weakness isn't a miz3 goal, for then you efforts
> would be wasted.

My theory would be that the problem is that MESON is bad at equational 
reasoning.  All you need to do (easy for me to say, of course) is to 
occasionally use rewriting as well as MESON.

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, John!  Please take my code whenever you like.  I'm done coding, and 
I'll regard my tar.gz file to be final after I fold my miz3 improvement back 
into my paper and finish my Miz3Tips file, which only requires me to understand 
Freek's syntax, and he just made a contribution to that, explaining that miz3 
definitely allow ending a proof with the final semicolon
  end;
`;;
These two matters won't take more than 2 weeks.  Understanding HOL might take 
longer, but that's not needed for you to distribute my code.  Thanks again for 
offering to include my code in your distribution.  The stronger my ties are to 
the HOL community, the better the chances of my math paper is.  The math folks 
and K-12 math ed folks would like to know that the HOL community thinks that 
e.g. teaching real axiomatic geometry with a proof assistant is possible. 

   Generally speaking, I'd say that "the automation is too powerful"
   is a problem we'd love [miz3] to have!

Great!  Right now it's not powerful enough for me.  

   Among other things, this makes MESON relatively inefficient at
   using a logical equivalence |- !x. P[x] <=> Q[x] to "rewrite" P to
   Q inside another formula; the length of the required proof grows
   with the size of that formula, and replacement inside quantifiers
   may expand the search space further because you need to examine
   different instantiations. I think that accounts for your
   time-consuming B4' derivation, for example.

Excellent, and for B4', we can say P = open (A,B) and Q = \X. Between A X B:

let IN_Interval = thm `;
 ! A B X. X IN open (A,B) <=> Between A X B
 by Interval_DEF, IN_ELIM_THM, REWRITE_TAC`;;

Is there any easy fix for this?  Freek noticed that REWRITE_TAC often improved 
speed. I think you're saying that I'm not really having a set theory problem, 
but that set theory often involves |- !x. P[x] <=> Q[x].

   The description of HOL in the Logic manual is based on a formal
   semantics inside set theory, developed by Andy Pitts. 

I see Andy wrote a paper with your advisor The HOL Logic and System but I can't 
find a pdf for it.  Should I read that? 

   While this might be considered the ultimate reference, I'm not sure
   that it's necessarily the easiest place to start, even for a
   mathematician, if you want a satisfying intuitive understanding of
   the logic. 

That's been my experience, but I think my problem is that the stuff I don't 
know is assumed to be already understood.  Math papers of course always have 
this problem.  

   My own (perhaps unhelpful) point of view is that if you think of
   types as nonempty sets, you can pretty much read statements at face
   value with the ordinary mathematical sense of "->" as function
   space etc. 

That's helpful and how I think of it, and I learned it from your tutorial.  But 
I'd like to really understand.  I want to explain this to my math audience, who 
all understand ZFC.  Greenberg e.g. posted very literate math logic in his 
recent Amer Math Monthly survey 
http://www.jstor.org/stable/10.4169/000298910X480063
What confuses me is that I understand how a computer can verify FOL proofs, or 
even construct them, so if we use ZFC, we can do modern math on computers.  I 
want to understand the analogous picture with HOL.  And I can't even imagine 
how a computer can do HOL if it's not using axioms with something very much 
like FOL!  It isn't that I like ZFC, and as Rob pointed out, I'd never 
understood the F part, the replacement axiom.  It's just something I was taught 
in math classes.

   I admit that polymorphic type variables slightly spoil this naive picture. 

And I'm using that from sets.ml, and even wrote some of my own:
let union = new_definition
  `! s t:A->bool. s union t = \ x. x IN s \/ x IN t`;;
let union_SUBSET = thm `;
  let s t u be A->bool;
  thus s union t  SUBSET  u  <=>  s SUBSET u /\ t SUBSET u
  by union, SUBSET, IN, BETA_THM`;;

I'm certainly happy with polymorphic Scheme code (map etc)!  And I don't see 
the problem with your naive picture: A is any set. 

   I don't think the correspondence between everyday informal
   mathematics and HOL is any more complicated than that between
   informal mathematics and ZF set theory.

Great, and as Paul Halmos's book Naive Set Theory explains, hardly any 
mathematicians understand how to use ZFC to construct the real numbers and 
prove its basic properties.  So I don't insist on understand HOL any better 
than I already understand ZFC :)

   Yes, that's correct. This proof doesn't look very much like a
   normal axiomatic one: first it proves that cos(angle_sum) = -1

Thanks, and I haven't figured out your proof of this yet.  I do think this is 
obvious for right triangles, because the sine & cosine of the two non-right 
angles are transposed, and that must prove, by your calculus definition of 
angles, that they're complementary.  I just understood something related to 
this that's been bugging me for a while:

Trig is based on the arc-lengt

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks for the HOL lesson, Michael, and clarifying about theorem-proving!  Can 
you give me some advice on how to read your 45 page Logic manual?  I need to 
understand why 

   x : point [means] 
   "x is an element of the set point"  (the reading we can derive using the 
semantics)

Your Logic manual looks perfectly rigorous but it has real exposition problems 
for mathematicians like me.  Once I understand it, I'll try to make some 
suggestions on how to improve the exposition.  Perhaps it's written for people 
who already know everything that I'm struggling with.

   Who wouldn't rather be doing deep stuff?

I'd be happy to work on software verification, even it's "tedious in the 
computer, and unimaginably tedious with pen and paper".  Right now I don't have 
the skill, and my next step is to learn procedural proofs.  Let's try to settle 
this miz3 biz, and my first step is:

Josef, my conjecture was wrong, and I regret my disparaging remarks about Mizar 
monkeying around with timeout numbers.  Piotr Rudnickii's article Obvious 
Inferences explains very interesting and sensible FOL, and his Herbrand stuff 
is discussed in John's book.  But my larger points (or Michael's) still hold, 
as Piotr explains:

PR> In defining the class of obvious inferences there is a danger of
PR> introducing a discrepancy between the user's sense of an obvious
PR> inference and what the proof-checker is able to accept.

Right, no FOL can't define what humans mean by obvious, so if Mizar's Herbrand 
obvious inference stuff actually captures our meaning of obvious, we're hitting 
Michael's sweet spot, and thinking Mizar always captures obvious our meaning of 
obvious is an illusion.

PR> Firstly, the goal is to force students to write proofs in detail,
PR> thus not all correct inferences have to be accepted.

I am against this goal, and John has several times posted it is not his goal, 
most strongly today:

JH> Generally speaking, I'd say that "the automation is too powerful"
JH> is a problem we'd love [miz3] to have!

Michael, the issue with Freek and miz3 is whether Freek intended to force 
students to write proofs in detail by setting timeout = 1 in miz3.  I believe 
(not sure) that he said that was not his intention.  What we know for sure is 
that Freek 
1) often explains that one should set the timeout higher, even to -1 (no 
timeout) 
2) explained the reason for timeout = 1: to limit user frustration when miz3 is 
trying very hard to prove something that's obviously wrong.  By setting timeout 
= 1, you get immediate feedback.
What I said, and Freek didn't necessarily agree with, is that this immediate 
feedback is particularly important for new users, and I feel quite comfortable 
with timeout = 50.  I think Freek still often uses timeout = 1 for immediate 
feedback.   
All this makes for a good comparison between Freek and Heineken, which installs 
beer bottle tops to prevent stores and consumers from spilling the beer, not to 
force users to drink less.  

   And really, why do we care?  

That's easy!  I want a smart HOL guy like you to think about how we can make 
miz3 (holby, actually) more powerful.  I'm having a bad interaction, I hazily 
conjecture, between the FOL that MESON is good at and the set theory in my 
paper.  For that, you must understand that intentional weakness isn't a miz3 
goal, for then you efforts would be wasted.  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

Thanks a lot for the detailed discussion of how the angle sum theorem
is typically proved in standard texts, and how the formalization goes.
It's been chastening to me to discover how hard it can be to formalize
what I thought was easy during my schooldays!

| let ANGLES_ADD_BETWEEN = prove
|  (`!A B C D:real^N.
| between C (A,B) /\ ~(D = A) /\ ~(D = B)
| ==> angle(A,D,C) + angle(C,D,B) = angle(A,D,B)`, [...] );;
|
| I think that means you didn't use this or any other angle betweenness
| results  in your proof, and that shocks me.   I should take your
| proof as an incentive to learn procedural proofs.

Even if you don't learn how to write procedural proofs, it wouldn't be
too hard for you to step through existing ones step-by-step. I admit
that it's a bit tricky to do this when one step generates multiple
subgoals. Mark Adams's "Tactician" can unwrap such proofs
automatically, but here is an example where I just unwrapped it by
hand. You should be able to copy what follows, though the first
"needs" line takes a long time since it loads a lot of theories. You
can see the sequence of goals that gets generated.

  needs "Multivariate/geom.ml";;

  g `!A B C:real^N. ~(A = B /\ B = C /\ A = C)
==> angle(B,A,C) + angle(A,B,C) + angle(B,C,A) = pi`;;
  
  e(REPEAT GEN_TAC THEN MAP_EVERY ASM_CASES_TAC
 [`A:real^N = B`; `B:real^N = C`; `A:real^N = C`] THEN
ASM_SIMP_TAC[ANGLE_REFL_MID; ANGLE_REFL; REAL_HALF; REAL_ADD_RID] THEN
REPEAT(FIRST_X_ASSUM SUBST_ALL_TAC) THEN
REPEAT(POP_ASSUM MP_TAC) THEN REWRITE_TAC[REAL_ADD_LID; REAL_HALF]);;

  e(REPEAT STRIP_TAC THEN MATCH_MP_TAC COS_MINUS1_LEMMA);;

  e(ASM_SIMP_TAC[TRIANGLE_ANGLE_SUM_LEMMA; REAL_LE_ADD; ANGLE_RANGE]);;

  e(MATCH_MP_TAC(REAL_ARITH
 `&0 <= x /\ x <= p /\ &0 <= y /\ y <= p /\ &0 <= z /\ z <= p /\
  ~(x = p /\ y = p /\ z = p)
  ==> x + y + z < &3 * p`));;

  e(ASM_SIMP_TAC[ANGLE_RANGE] THEN REPEAT STRIP_TAC);;

  e(REPEAT(FIRST_X_ASSUM(MP_TAC o GEN_REWRITE_RULE I [ANGLE_EQ_PI_DIST])));;

  e(REPEAT(FIRST_X_ASSUM(MP_TAC o GEN_REWRITE_RULE RAND_CONV
 [GSYM VECTOR_SUB_EQ])));;
   
  e(REWRITE_TAC[GSYM NORM_EQ_0; dist; NORM_SUB] THEN REAL_ARITH_TAC);;

| You're clearly using the calculus definition of angles: acs((x dot y)
| / (norm x * norm y)), and that could conceivably simplify the proof.

Yes, that's correct. This proof doesn't look very much like a normal
axiomatic one: first it proves that cos(angle_sum) = -1 and that 
0 <= angle_sum < 3 pi, and then from those gets the fact that
angle_sum = pi using various trig formulas.

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

| Thanks, John!  I'd be thrilled if you included my code in the HOL Light
| distribution (miz3 dir sounds good)!  I think it would improve my paper's
| chance of being accepted.

OK, I'll be very happy to incorporate it whenever you regard it as
final. Or if you prefer, I can put a preliminary version in now and it
can be updated later.

| I don't understand the technicalities, but may I make a suggestion?
| No matter how powerful you make miz3, users can still put extra
| details in their proofs. The purpose of extra details is good
| pedagogy, so that another human can read the code and learn the proof.
| I think my miz3 code is almost as readable as my paper, especially
| with the fancy HOL4/Isabelle-style math fonts.  If miz3 is really
| powerful, then users are on the "honor system" as to whether they
| really understand their own proofs, but math is already on the "honor
| system", so it's fine.

That's certainly a reasonable position. Of course, it also requires a
reliable proof assistant (so that if it does prove a theorem you can
be pretty sure it's right) and a good understanding of the underlying
definitions or axioms (so that you are not deluded about what is being
proved).

Generally speaking, I'd say that "the automation is too powerful" is a
problem we'd love to have! The situation probably arises more often in
this domain of synthetic geometry because you really are trying to
follow strict axiomatic reasoning using first-order logic, and in that
case the computer can quite often beat the human (as in the Los
puzzle). But in areas where the human is using some higher level of
intuition and a mixture of domain-specific reasoning and logic, being
beaten by the machine is a bit more unusual.

| I wasn't clear about my time-table yesterday.  I have 4 tasks left, in
| increasing order of difficulty:
| 1) finish formalizing the plane geometry parts of my 26 page paper (close to
| done)
| 2) port the new geometry rigor from my code to my paper (shouldn't take long,
| and then I can write to Hartshorne)
| 3) finish my miz3 users guide MizTips (I must understand Freek's syntax &
| semantics lectures)
| 4) understand HOL (I'm reading the HOL4 Logic manual)
|
| The last task sounds hard to me, and possibly I won't do a good job.

The description of HOL in the Logic manual is based on a formal
semantics inside set theory, developed by Andy Pitts. While this might
be considered the ultimate reference, I'm not sure that it's
necessarily the easiest place to start, even for a mathematician, if
you want a satisfying intuitive understanding of the logic. My own
(perhaps unhelpful) point of view is that if you think of types as
nonempty sets, you can pretty much read statements at face value with
the ordinary mathematical sense of "->" as function space etc. (I
admit that polymorphic type variables slightly spoil this naive
picture.) I don't think the correspondence between everyday informal
mathematics and HOL is any more complicated than that between informal
mathematics and ZF set theory.

| So if you want to improve miz3 for my paper, you'll have time.
| What I would most like you to look at my code and figure out why
| MESON is working so hard.  I have 16 MESON solved at numbers over
| 200,000, but I don't think I ever ask miz3 to do anything as hard
| as the Los Logic problem, which had a MESON solved at number about
| 20,000.

In general, algorithms like MESON for first-order proof search work by
looking for proofs in certain standard forms. By imposing such
restrictions, you sometimes need proofs that are longer than you might
expect, but the advantage is that the search space to enumerate when
trying to find proofs becomes smaller. There is a trade-off involved.

The MESON algorithm is a form of model elimination, which is similar
to another well-known algorithm called tableaux, except that (1) the
formulas get put into clausal form initially, and (2) only tableau
deductions with a certain "connection" between formulas are allowed.

Among other things, this makes MESON relatively inefficient at using a
logical equivalence |- !x. P[x] <=> Q[x] to "rewrite" P to Q inside
another formula; the length of the required proof grows with the
size of that formula, and replacement inside quantifiers may
expand the search space further because you need to examine different
instantiations. I think that accounts for your time-consuming B4'
derivation, for example.

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 30/08/2012, at 17:58, Bill Richter  wrote:

> Michael, I detect in your previous post a disturbing definition of 
> theorem-proving:

>   [Bill] is mathematically sophisticated but a novice as far as
>   theorem-proving is concerned.  

> I think I'm quite good at theorem-proving (I have 11 papers published in Math 
> journals).  

Of course, I meant "mechanical theorem-proving in a system such as HOL Light" 
when I wrote "theorem-proving".  Your ability to prove theorems in the 
traditional sense is what I meant to imply by describing you as mathematically 
sophisticated. 

>   Setting that timeout to 1 by default is intentional shackling.  So,
>   miz3 is indeed intentionally shackled.

> No, because `intentional' refers to the mental states of the actor, and 
> `shackling' here means to force the proof assistant to make only small 
> inference leaps.

Freek intentionally set the default limit to 1, knowing full well that it would 
limit the ability of the theorem prover to make inference leaps.   If he'd 
wanted the default to be -1, he could have made it thus.  The beer bottle 
analogy is bogus because Heineken can't ship their bottles already open.  
Freek, on the other hand, could ship miz3 with a default of -1 if he wanted to. 
 Perhaps he now will because of this very discussion...

Put it another way: out of the box, the system makes smaller inference leaps 
than it might otherwise because of an explicit decision by an informed system 
designer.   That is intentional shackling.  And really, why do we care?  If you 
want think of HOL Light + miz3 as an unshackled dove, that's your privilege.  I 
will not stir the pot any further.

> I'm OK until 1.2.2 Semantics of types, where I get befuddled.  It sounds like 
> a model M is only defined on type constants, which sounds easy, and somehow 
> forces a definition of M on polymorphic types, and the only type constants I 
> know of are the atomic types bool, ind and the arity-2 operator ->, and the 
> Hilbert choice operator which doesn't isn't relevant to my geometry.   So I'm 
> a long way from seeing how to do the set theory I'm used to in HOL.  

The set theory you do in HOL is not so far from set theory in traditional ZFC.  
When you assert your type of point, you say that what follows is all going to 
happen with respect to an unspecified non-empty set that you're calling 
"point".  When you write

  x : point

you can read this as either

  "x has type point"  (the HOL reading)

or

  "x is an element of the set point"  (the reading we can derive using the 
semantics)

When you write 

  UNION : (point -> bool) -> (point -> bool) -> (point -> bool)

you are referring to the function which constructs the "or" of two predicates 
over elements of the set point.  Because predicates over points can be freely 
seen as subsets of the set point, this maps exactly to the traditional ZFC 
union constant.  

Everything you do in HOL can be seen as a ZFC construction that has been 
bounded above by various non-empty sets.

> I think it's a question about aims.  Published math papers often rely on 
> calculations performed by computer programs.  Mathematicians will no doubt 
> soon be relying on their PA for much more help.  I'm not trying to say this 
> is a bad idea.  My aim is for folks to learn mathematical proofs that can be 
> done without  computer help, as I think it's a valuable mental discipline.  
> I'd recommend to everyone e.g. to understand Hilbert axiomatic geometry 
> without computers.  I strongly think that understanding math proofs without 
> computers will make one better at formal proofs, and that using a PA to 
> verify e.g. Hilbert geometry vastly increases one's pleasure and 
> understanding of the "paper/pencil" math.  I imagine most folks using PAs 
> have much more practical aims, e.g. debugging software.  I'm really hoping to 
> learn how to debug software with a PA as well. 

In my experience, getting PAs to do maths is generally much more fun than 
getting them to do software verification.  People often characterise 
verification work as shallow but broad, where broad really just means tedious 
in the computer, and unimaginably tedious with pen and paper.  Who wouldn't 
rather be doing deep stuff?

Best,
Michael
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Michael, I detect in your previous post a disturbing definition of 
theorem-proving:

   [Bill] is mathematically sophisticated but a novice as far as
   theorem-proving is concerned.  

I think I'm quite good at theorem-proving (I have 11 papers published in Math 
journals).  I'm a novice at formalizing theorems, i.e. using proof assistants 
to verify a proof or to prove theorems.  And even with formal proofs, I've 
developed some skill at declarative proofs, so I'm really only a novice at 
procedural formal proofs.  I think that's the usual meaning of 
`theorem-proving' here. 

   Setting that timeout to 1 by default is intentional shackling.  So,
   miz3 is indeed intentionally shackled.

No, because `intentional' refers to the mental states of the actor, and 
`shackling' here means to force the proof assistant to make only small 
inference leaps.   Heineken sells beer bottles that can't be opened by hand.  
We must ask how Heineken and Freek intend for us to use their products.  This 
isn't a question to settle with objective data such as default timeout values 
or the fact that you can't (except for those awful twistoffs!) remove the beer 
bottle top without a special tool.  Since Heineken intends for us to use a 
bottle opener, they're not intentionally shackling their beer bottles, i.e. 
preventing us from drinking the beer.  Since Freek intends for us to raise the 
timeout (he often posts that -1 means no timeout), he's not intentionally 
shackling miz3.  

I wish we were in agreement about theorem-proving and intentional shackles, 
because I think I'll need a lot of your help to understand your HOL4 Logic 
manual, which looks perfectly rigorous but I seem to be missing the context.  
I'm OK until 1.2.2 Semantics of types, where I get befuddled.  It sounds like a 
model M is only defined on type constants, which sounds easy, and somehow 
forces a definition of M on polymorphic types, and the only type constants I 
know of are the atomic types bool, ind and the arity-2 operator ->, and the 
Hilbert choice operator which doesn't isn't relevant to my geometry.   So I'm a 
long way from seeing how to do the set theory I'm used to in HOL.  Your manual 
is a blur to me until 2.3.1 The HOL deductive system, which all looks perfectly 
fine, but I don't know why it's enough.  What I want is just to understand one 
simple example, HOL in my geometry 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
which is now finished at 4565 lines, and includes a proof without the parallel
OppositeSidesCongImpliesParallelogram_THM : thm =
  |- ∀A B C D.
 Quadrilateral A B C D
 ⇒ ∡ A B C ≡ ∡ C D A  ∧  ∡ D A B ≡ ∡ B C D
 ⇒ Parallelogram A B C D

Cris wrote something similar to what you wrote about Los's logic result

   In learning situations I certainly would want to be able to control
   the power level of a proof assistant.

Since you can't prevent students from using a more powerful PA (such as 
Vampire), you'll have to make rules about what constitutes an acceptable proof 
in your class.  In the math courses I want to teach, my rule would be you have 
to be able to explain your proof to me.  In classes on hardware verification 
where humans can't understand the proofs with pencil/paper, different rules 
would be needed. I'm mostly saying that I think such rules show the students 
more respect than shackling the offical class proof assistant (PA). 

I think it's a question about aims.  Published math papers often rely on 
calculations performed by computer programs.  Mathematicians will no doubt soon 
be relying on their PA for much more help.  I'm not trying to say this is a bad 
idea.  My aim is for folks to learn mathematical proofs that can be done 
without  computer help, as I think it's a valuable mental discipline.  I'd 
recommend to everyone e.g. to understand Hilbert axiomatic geometry without 
computers.  I strongly think that understanding math proofs without computers 
will make one better at formal proofs, and that using a PA to verify e.g. 
Hilbert geometry vastly increases one's pleasure and understanding of the 
"paper/pencil" math.  I imagine most folks using PAs have much more practical 
aims, e.g. debugging software.  I'm really hoping to learn how to debug 
software with a PA as well. 

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Cris Perdue]

Bill, Michael, and all,

Let me second Michael's comments right from the start. He has expressed
most gracefully much of what I thought needed to be said.

On Tue, Aug 28, 2012 at 11:11 PM, Bill Richter <
rich...@math.northwestern.edu> wrote:

> Thanks, Michael!  I like what you wrote about (me and) the student with
> "little sophistication when it comes to writing proofs,"  but I can't see
> we're helping by shackling their proof assistant.  I want people to learn
> how to write and understand mathematical proofs, and I think proof
> assistants (especially miz3) can help students learn.  It worked for me!  I
> understand Hilbert geometry a lot better after formalizing my paper.  I
> could see this helping students at every level.  Does anyone (other than
> Cris, who I know does) share this objective?
>
>1. the student doesn't waste time waiting for the prover to give up
>on unrealistic or unprovable goals.  Fast feedback is universally
>recognised as a good thing when using a system: having it come back
>fast and say "No. Make your proof better" has to be a good thing
>for learning how to make better proofs.
>
> Great, and that's exactly what Freek and I said earlier about why timeout
> is set to 1 by default in miz3.  Do you agree that miz3 isn't intentionally
> shackled, and that John would be delighted if we figured out how to make it
> more powerful?
>
>2. if the student does occasionally get the backend prover to fluke
>a hard result, they miss out on the pedagogically valuable exercise
>of actually proving that result.
>
> Doesn't the student realize they didn't prove the theorem?  Shouldn't they
> say, that's great my PA proved the theorem (I want to have a powerful PA),
> and now let's see if I can prove it too.  If so, they don't miss out, and I
> could see going for occasional flukes as a way for the student to test
> their intuition.
>

For highly motivated students this may work at least most of the time. But
if the student is not so motivated, or just in a hurry, he or she is very
likely to move on immediately upon finding a solution. In learning
situations I certainly would want to be able to control the power level of
a proof assistant.




>
>Do you really want a student to be able to come back to you with
>that theorem due to Los, and say "Oh, I proved it by waiting for
>meson to finish."
>
> Well, they'd only wait a few seconds (a 20,000 solved at MESON number is
> quick: my code runs 15 minutes on my slow home computer).  I don't know
> what you mean by `able'.  I want to the students to know the difference
> between them understanding a proof and MESON proving it.  If they're
> learning to prove theorems and write them up, they should know that by the
> time they get to a really tough result like Los's.
>
>Bill thought that proving it by hand was interesting and valuable,
>and discussed Rob Arthan's proof at length.  Surely the value that
>Bill derived from that exercise would be just as great for
>students.
>
> Yeah, absolutely!  I'd tell the kids what I learned from Rob, you can
> emulate what MESON did by calculating the possibilities, and then tell them
> to try a bold frontal attack of looking at 4 points, or maybe even 3.  I'd
> want to know if any of them could replicate Rob's brilliant success.
>
> So I say if the students want to learn proofs, a good PA can really help
> them, but let's respect the students and let them set the timeouts.  If the
> students don't want to learn proofs, I doubt we can force them to by
> shackling the PA.
>

The negative sound of the word "shackled" may be coloring the discussion.
Bill, you seem to not like the system to be limited, and you have reasons
for that. Others of us don't think that more power in the prover is
necessarily better in learning situations, but that doesn't mean one
approach is always right and the other always wrong.

What I myself would wish for in a learning situation would be "tunability"
of the proof assistant to help match it with the skill set of the students.
It seems easier to motivate students to develop their skills if the proof
assistant functions basically as a checker. I do see your point that maybe
it's not bad to guess at a step sometimes. Hopefully someday we can test
these questions empirically.

Beeson's system is interesting in that it gives hints and tailors the hints
to a level appropriate to the student's skills.  So a low-level hint could
mention applying commutativity, where a higher-level hint would be to
regroup terms, a higher-level operation.

Cheers,
Cris



>
> Maybe I'm being too idealistic.  I think hand calculators are a great way
> for kids to learn manual arithmetic well enough to believe the
> distributive, associative etc laws that are so vital to understanding
> Algebra.  A good exercise is writing 1/7 as a repeating decimal and then
> turning that repeating decimal back into a fraction, and then reducing it
> to 1/7.  Well, tha

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 29/08/12 16:11, Bill Richter wrote:

> Great, and that's exactly what Freek and I said earlier about why
> timeout is set to 1 by default in miz3. Do you agree that miz3 isn't
> intentionally shackled, and that John would be delighted if we
> figured out how to make it more powerful?

Setting that timeout to 1 by default is intentional shackling.   So, miz3 is 
indeed intentionally shackled.

They're easy shackles to escape of course.  But they're there.

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Michael!  I like what you wrote about (me and) the student with "little 
sophistication when it comes to writing proofs,"  but I can't see we're helping 
by shackling their proof assistant.  I want people to learn how to write and 
understand mathematical proofs, and I think proof assistants (especially miz3) 
can help students learn.  It worked for me!  I understand Hilbert geometry a 
lot better after formalizing my paper.  I could see this helping students at 
every level.  Does anyone (other than Cris, who I know does) share this 
objective?  

   1. the student doesn't waste time waiting for the prover to give up
   on unrealistic or unprovable goals.  Fast feedback is universally
   recognised as a good thing when using a system: having it come back
   fast and say "No. Make your proof better" has to be a good thing
   for learning how to make better proofs.

Great, and that's exactly what Freek and I said earlier about why timeout is 
set to 1 by default in miz3.  Do you agree that miz3 isn't intentionally 
shackled, and that John would be delighted if we figured out how to make it 
more powerful?

   2. if the student does occasionally get the backend prover to fluke
   a hard result, they miss out on the pedagogically valuable exercise
   of actually proving that result.  

Doesn't the student realize they didn't prove the theorem?  Shouldn't they say, 
that's great my PA proved the theorem (I want to have a powerful PA), and now 
let's see if I can prove it too.  If so, they don't miss out, and I could see 
going for occasional flukes as a way for the student to test their intuition.

   Do you really want a student to be able to come back to you with
   that theorem due to Los, and say "Oh, I proved it by waiting for
   meson to finish."  

Well, they'd only wait a few seconds (a 20,000 solved at MESON number is quick: 
my code runs 15 minutes on my slow home computer).  I don't know what you mean 
by `able'.  I want to the students to know the difference between them 
understanding a proof and MESON proving it.  If they're learning to prove 
theorems and write them up, they should know that by the time they get to a 
really tough result like Los's.  

   Bill thought that proving it by hand was interesting and valuable,
   and discussed Rob Arthan's proof at length.  Surely the value that
   Bill derived from that exercise would be just as great for
   students.

Yeah, absolutely!  I'd tell the kids what I learned from Rob, you can emulate 
what MESON did by calculating the possibilities, and then tell them to try a 
bold frontal attack of looking at 4 points, or maybe even 3.  I'd want to know 
if any of them could replicate Rob's brilliant success.

So I say if the students want to learn proofs, a good PA can really help them, 
but let's respect the students and let them set the timeouts.  If the students 
don't want to learn proofs, I doubt we can force them to by shackling the PA.

Maybe I'm being too idealistic.  I think hand calculators are a great way for 
kids to learn manual arithmetic well enough to believe the distributive, 
associative etc laws that are so vital to understanding Algebra.  A good 
exercise is writing 1/7 as a repeating decimal and then turning that repeating 
decimal back into a fraction, and then reducing it to 1/7.  Well, that's a lot 
easier to do if you get your calculator to do some of the work.  This of course 
hasn't been the effect so far of calculators in math classes!  Many Calculus 
students told me that they can't do algebraic simplifications because they 
don't have to, their calculators will graph functions any way they type them 
in!  

BTW the great mathematician Bill Thurston just died.  He wrote a very 
interesting article 
On Proof and Progress in Mathematics
Bulletin of the A.M.S. 1994
http://www.ams.org/journals/bull/1994-30-02/S0273-0979-1994-00502-6/S0273-0979-1994-00502-6.pdf
I posted a tribute on a topology listserve 
https://lists.lehigh.edu/pipermail/algtop-l/2012q3/001462.html talking about 
Thurston's interest in computers he showed in this article.

Josef, I don't think you answered my question.  But we're even, because I 
haven't read Piotr's article.  But I will conjecture, on the basis of Michael's 
great post about illusions and sweet spots, that there is no good way for the 
PA to restrict the users to "obvious inferences."  That shackling the PA in 
this way is a hit or miss game of setting various timeouts & limitations, which 
might work in a lot of cases, but there's no science to it, we're just 
monkeying with various numbers.  I suspect it's the inelegance of this that 
monkeying around with the timeout & depth numbers that bothered Michael, and it 
bothers me now too.  OK, I've made my conjecture, now I can go read Piotr :)

Let me stress that I think that Mizar made a fantastic contribution, continued 
by John & Freek with holby/miz3, of ALLOWING us to write human readable proofs. 
 I don't consider that Mizar made a

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 28/08/12 13:29, Bill Richter wrote:
>> Yes, Mizar is certainly shackled in the way Michael described.

> I can't figure out your position.  I agree there might be some value in
> shackling for retrieval from huge libraries.  Why don't we concentrate on
> education.  I contend that shackling the students' proof assistant is bad
> design.  Michael did not say this, but I say it after listening to Michael,
> and I'm glad that miz3 is not shackling the students (me, right now).

We can imagine two sorts of student here.  One is the person who is 
mathematically sophisticated but a novice as far as theorem-proving is 
concerned.  This person (i.e., Bill) manifestly doesn't want a "shackled" 
backend prover.

However, if the student has little sophistication when it comes to writing 
proofs, I think there are two advantages in having a shackled prover:

1. the student doesn't waste time waiting for the prover to give up on 
unrealistic or unprovable goals.  Fast feedback is universally recognised as a 
good thing when using a system: having it come back fast and say "No. Make your 
proof better" has to be a good thing for learning how to make better proofs.

2. if the student does occasionally get the backend prover to fluke a hard 
result, they miss out on the pedagogically valuable exercise of actually 
proving 
that result.  Do you really want a student to be able to come back to you with 
that theorem due to Los, and say "Oh, I proved it by waiting for meson to 
finish."  Bill thought that proving it by hand was interesting and valuable, 
and 
discussed Rob Arthan's proof at length.  Surely the value that Bill derived 
from 
that exercise would be just as great for students.

Michael



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Josef Urban]

Hi Bill,

> I've worked very hard to make my miz3 Hilbert axiomatic geometry code 
> readable, and taking huge leaps nobody could follow would be 
> counterproductive. But I'm against shackling the proof assistant, as we agree 
> Mizar does but miz3 does not:
>
>Yes, Mizar is certainly shackled in the way Michael described.
>
> I can't figure out your position.  I agree there might be some value in 
> shackling for retrieval from huge libraries.  Why don't we concentrate on 
> education.  I contend that shackling the students' proof assistant is bad 
> design.  Michael did not say this, but I say it after listening to Michael, 
> and I'm glad that miz3 is not shackling the students (me, right now).

My (current :-) position is that the code in large math libraries
should be easy to write, read and maintain. For easy writing, you want
the strongest possible AI assistance, for reading you want it
transformed into something human-understandable, and for maintenance
you want it transformed into something easily checkable by a computer,
possibly by robust and predictable algorithms that give you enough
feedback when proof checking fails. There are various tensions between
these goals and people solve them in various ways, this is research
:-).

Josef



>
> --
> Best,
> Bill
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks for the  reference to Piotr R's article, Josef, and I'll read it. 

   Yes. But will they? 

I will!  I've worked very hard to make my miz3 Hilbert axiomatic geometry code 
readable, and taking huge leaps nobody could follow would be counterproductive. 
But I'm against shackling the proof assistant, as we agree Mizar does but miz3 
does not:

   Yes, Mizar is certainly shackled in the way Michael described.

I can't figure out your position.  I agree there might be some value in 
shackling for retrieval from huge libraries.  Why don't we concentrate on 
education.  I contend that shackling the students' proof assistant is bad 
design.  Michael did not say this, but I say it after listening to Michael, and 
I'm glad that miz3 is not shackling the students (me, right now).

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Josef Urban]

Hi Bill,

On Mon, Aug 27, 2012 at 7:19 AM, Bill Richter
 wrote:
> Thanks, Josef, that's very helpful, and you're saying I was wrong (but right 
> originally)
>
>I think the original intention behind the "weakness" was to capture
>the right level of reasoning that would be "obvious" to humans,
>i.e., not too strong to puzzle the readers and not too weak to
>drown them in detail. This motivation is probably still quite strong
>
> Michael taught me that aiming for obvious/not-tedious is bad design (see his 
> post about "illusion" and "sweet spot"),

I am not sure I can read that e-mail as suggesting that Mizar/miz3 is
"bad design". But certainly, there are many opinions out there in the
ITP world.

> and all the evidence is that John isn't trying to weaken miz3 in this way.  
> Folks can still write readable proofs, making only "obvious" steps, even if 
> the proof assistant is powerful enough to take much bigger inference leaps.

Yes. But will they? I think that for example most of the SW/HW
verification people don't care much about this, they often want to
have the job done ASAP. So people like Andrzej and Georges (who have
to maintain their large math libraries) choose to limit the power of
their proof *checking* procedures. I believe both of them have been
reasonably successful in large-scale math formalization. Also note
that I disagree with both of them when it comes to the use of strong
(often external) proof *finding* procedures.

> I respectfully submit that John's code for "holby" is not a good description 
> of what Mizar does,

It is not a full description, but the best which is publicly
available. The code in it will give you an idea what Mizar does.

> and my evidence is that my miz3 Tarski code 
> http://www.math.northwestern.edu/~richter/TarskiAxiomGeometryCurry.ml makes 
> heavy use of MESON, even using Freek's substitution of HOL Light currying for 
> Mizar-friendly infixes.  I think Mizar does a ton of things that John didn't 
> code up, but that's OK because MESON does the job: "and finally if all else 
> fails using MESON_TAC[]."   You seem to understand this even, writing

Yes, John uses MESON as a fallback, but the MESON code has little to
do with Mizar proof checking.

>
>Both "MESON" and "by" are the respective workhorses in HOL Light
>and Mizar, but they do different things.
>
> Thanks for the links to Freek's article.  Can you tell me again the links to 
> the
> "obvious inference" papers by Davis and Rudnicki?

http://rd.springer.com/article/10.1007/BF00247436
http://www.springerlink.com/content/j42q143754533x73/

>
>There are really many proof search procedures (and ways how to
>limit them and combine them).
>
> I'd interpret this as saying that Mizar is doing much the same kind of FOL 
> proving that MESON does,

No. They do different things.

> but that Mizar, unlike MESON, is shackled with various limitations aimed at 
> hitting Michael's "sweet spot".

Yes, Mizar is certainly shackled in the way Michael described.

Josef

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Josef, that's very helpful, and you're saying I was wrong (but right 
originally)

   I think the original intention behind the "weakness" was to capture
   the right level of reasoning that would be "obvious" to humans,
   i.e., not too strong to puzzle the readers and not too weak to
   drown them in detail. This motivation is probably still quite strong

Michael taught me that aiming for obvious/not-tedious is bad design (see his 
post about "illusion" and "sweet spot"), and all the evidence is that John 
isn't trying to weaken miz3 in this way.  Folks can still write readable 
proofs, making only "obvious" steps, even if the proof assistant is powerful 
enough to take much bigger inference leaps.  I respectfully submit that John's 
code for "holby" is not a good description of what Mizar does, and my evidence 
is that my miz3 Tarski code 
http://www.math.northwestern.edu/~richter/TarskiAxiomGeometryCurry.ml makes 
heavy use of MESON, even using Freek's substitution of HOL Light currying for 
Mizar-friendly infixes.  I think Mizar does a ton of things that John didn't 
code up, but that's OK because MESON does the job: "and finally if all else 
fails using MESON_TAC[]."   You seem to understand this even, writing 

   Both "MESON" and "by" are the respective workhorses in HOL Light
   and Mizar, but they do different things.

Thanks for the links to Freek's article.  Can you tell me again the links to the
"obvious inference" papers by Davis and Rudnicki?  

   There are really many proof search procedures (and ways how to
   limit them and combine them).

I'd interpret this as saying that Mizar is doing much the same kind of FOL 
proving that MESON does, but that Mizar, unlike MESON, is shackled with various 
limitations aimed at hitting Michael's "sweet spot".

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

   I'll be interested to see how the angle sum proof looks in
   axiomatic style. I remember being a bit surprised and disappointed
   at how messy the "vectorial" proof is that I once formalized. (See
   TRIANGLE_ANGLE_SUM in "Multivariate/geom.ml").

John, I now have the angle sum proof formalized, and thanks to your 
encouragement I improved both the statement and the proof.  It's the last 
result in my 4400 lines of miz3 Hilbert axiomatic geometry code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz

HilbertTriangleSum : thm =
  |- !A B C.
 ~Collinear A B C
 ==> (?E F.
  B IN open (E,F)  /\  C IN int_angle A B F  /\
  angle E B A === angle C A B  /\  angle C B F === angle B C A)

I'd like to compare this statement to what you proved.   First, you proved the 
theorem and I didn't, but what I did is the best you can do with Hilbert's 
axioms.  Next, I'm just rigorizing the standard proof you find in every high 
school geometry book, and your proof looks a lot different.  Here's how the 
axioms of Birkhoff, Moise & Venema for an angle measure function `mu' get your 
theorem from mine.  

We're given a triangle ABC (~Collinear A B C).  There exists points E & F on a 
line with B with B between E & F (B IN open (E,F)).  That means that the angles 
EBA and BAF are supplementary, so Venema etc show that 
pi = mu(EBA) + mu(ABF).  By an axiom of Venema etc, since C is in the interior 
of the angle ABF (C IN int_angle A B F), 
mu(ABF) = mu(ABC) + mu(CBF).
By Venema etc's axioms, my two angle congruences give us 
mu(EBA) = mu(CAB)  /\  mu(CBF)  = mu(BCA).
Now we're donew:

pi = mu(EBA) + mu(ABF) 
   = mu(EBA) + mu(ABC) + mu(CBF) 
   = mu(CAB) + mu(ABC) + mu(BCA)

That's the standard proof, which I've never seen rigorized anywhere, even in 
Moise & Downs's otherwise excellent (and out-of-print) Geometry text: by the 
parallel postulate there's a unique line m through B which is parallel to AC, 
and by the Alternate Interior Angles thm and its converse, the three angles you 
see on one side of m at B are congruent to our 3 angles.   To rigorize the 
proof you need to define alternate interior angles (Euclid didn't do it) and to 
prove that C IN int_angle A B F.  It's standard Hilbert betweenness stuff, 
requiring the Crossbar thm which Moise & Downs proved, in a unique wonder among 
high school Geometry texts.  I'm thinking that Moise & Downs failed to prove 
the triangle sum theorem because traditionally it's tied with the much harder 
and weaker non-Euclidean analogue, which I still don't understand.  

I'm impressed by your short proof, but as I haven't grokked yet the procedural 
style yet (your "EAR_OF_BAT_TAC[]" is hilarious!), I can only make vague 
comments stimulated by your final thm/proof

let ANGLES_ADD_BETWEEN = prove
 (`!A B C D:real^N.
between C (A,B) /\ ~(D = A) /\ ~(D = B)
==> angle(A,D,C) + angle(C,D,B) = angle(A,D,B)`, [...] );;

I think that means you didn't use this or any other angle betweenness results 
in your proof, and that shocks me.   I should take your proof as an incentive 
to learn procedural proofs.  

Your result is the converse of the Crossbar thm, and in Hilbert-land is much 
easier than the Crossbar thm.  In your vector geometry the Crossbar thm is a 
standard exercise in intersecting straight lines, so you could easily prove it. 

You're clearly using the calculus definition of angles: acs((x dot y) / (norm x 
* norm y)), and that could conceivably simplify the proof.  Someone on hol-info 
wrote to me privately about this and I told him to post here.  I think it's 
fascinating that trig is based on a definition you need calculus for. The 
integral definition of arc-length defines the angle theta and the inverse trig 
functions acs, arcsin & arctan.  Then you need the inverse function theorem to 
semi-define their inverses cos, sin & tan.  

I'm including my results below, in what I think is much more readable math 
characters.  I wish the HOL4 folks could help you get these funny chars into 
HOL Light.  

-- 
Best,
Bill 

Crossbar_THM
  |- ∀ O A B D.
 ¬Collinear A O B  ∧  D ∈ int_angle A O B
 ⇒ ∃ G. G ∈ open (A,B) ∧ G ∈ ray O D ━ O

AlternateInteriorAngles_THM
  |- ∀ A B C E l m t.
 Line l ∧ A ∈ l ∧ E ∈ l ∧ 
 Line m ∧ B ∈ m ∧ C ∈ m ∧ 
 Line t ∧ A ∈ t ∧ B ∈ t ∧ 
 ¬(A = E) ∧ ¬(B = C) ∧ ¬(A = B) ∧ E ∉ t ∧ C ∉ t ∧ 
 ¬(C,E same_side t)  ∧  ∡ E A B ≡ ∡ C B A
 ⇒ l ∥ m

P |- ∀ P l. Line l ∧ P ∉ l ⇒ ∃! m. Line m ∧ P ∈ m ∧ m ∥ l

ConverseAlternateInteriorAngles_THM
  |- ∀ A B C E l m t.
 Line l ∧ A ∈ l ∧ E ∈ l ∧ 
 Line m ∧ B ∈ m ∧ C ∈ m ∧ 
 Line t ∧ A ∈ t ∧ B ∈ t ∧ 
 ¬(A = E) ∧ ¬(B = C) ∧ ¬(A = B) ∧ E ∉ t ∧ C ∉ t ∧ 
 ¬(C,E same_side t) ∧ l ∥ m
 ⇒ ∡ E A B ≡ ∡ C B A

HilbertTriangleSum
  |- ∀ A B C.
 

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Josef Urban]

Hi Bill,

> Josef, it sounds like you're saying that Mizar is intentionally weak, and 
> that the reason for weakness is to make it practical to make calls to the 
> huge Mizar library.

The reasoning is that speed implies easy refactoring, and that
facilitates optimization of the library. Making the library quickly
processable is also useful for all kinds of research over it and
processing of various kinds. The speed can really make a lot of
difference in how humans interact with computers. I think Linus
Torvalds once said that the raw speed of his "git" version control
system significantly changed the way he uses version control. With
massive parallelization (64 CPUs on one machine) I can now process the
whole MML below 10 minutes, and this kind of near-real-time
interactivity makes experimental research in large-scale formal math
quite a bit of fun. But I think the original intention behind the
"weakness" was to capture the right level of reasoning that would be
"obvious" to humans, i.e., not too strong to puzzle the readers and
not too weak to drown them in detail. This motivation is probably
still quite strong, although occasionally I hear even some Mizar
people say heresies like "Who reads the proofs?" :-).

> And so presumably if you make improvements in library calls, then Mizar would 
> want to become stronger.  Is that right?

The "library calls" are (in Mizar) theorems, definitions, and typing
automations. If they become stronger and more mutually compatible,
then formalization is indeed easier. Particularly the Coq people have
been recently doing a lot of research in how to make formal math as
re-usable as possible. It is a fairly interesting and nontrivial
topic.

> One thing I can't understand is how Mizar weakens itself in the first place.

One of the best descriptions is actually John's code for "holby" in
HOL Light :-). Also Freek has compiled a description here:
http://www.cs.ru.nl/~freek/mizar/by.ps.gz . The motivation is in the
"obvious inference" papers by Davis and Rudnicki that I already
mentioned.

>  Miz3 is as strong as MESON once you take Freek's constant advice and raise 
> the timeout.  I don't know much about proof assistants, but it's hard for me 
> to see how Mizar can be doing anything that different,

There are really many proof search procedures (and ways how to limit
them and combine them).

> and you seemed to say it yourself: [Mizar's] own "MESON" - "by".

That was a crude analogy, sorry for the confusion. Both "MESON" and
"by" are the respective workhorses in HOL Light and Mizar, but they do
different things.

Josef

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, something that convinced me that miz3 wants to be strong was stimulated 
by Josef, who got the FOL prover Vampire to give 1-line proofs of almost all of 
my Tarski miz3 results.  Eventually I tried doing the same in miz3, and I'm 
including my biggest success below.  In about 2 hrs on my fastest machine, with 
a MESON solved at number of over a million, miz3 verified a 1-line proof, where 
my real proof is 8 lines long and took me quite a long time to come up with.  
That's good evidence that even though miz3 may not be super-powerful, it's not 
trying to be weak. 

Josef, it sounds like you're saying that Mizar is intentionally weak, and that 
the reason for weakness is to make it practical to make calls to the huge Mizar 
library.  And so presumably if you make improvements in library calls, then 
Mizar would want to become stronger.  Is that right?  One thing I can't 
understand is how Mizar weakens itself in the first place.  Miz3 is as strong 
as MESON once you take Freek's constant advice and raise the timeout.  I don't 
know much about proof assistants, but it's hard for me to see how Mizar can be 
doing anything that different, and you seemed to say it yourself: [Mizar's] own 
"MESON" - "by".

-- 
Best,
Bill 

horizon := 0;; 
timeout := 8000;;

new_type("point",0);;
new_type_abbrev("point_set",`:point->bool`);;
new_constant("Line",`:point_set->bool`);;

let I1 = new_axiom
  `! A B.  ~(A = B) ==> ?! l. Line l /\  A IN l /\ B IN l`;;

let BiggerThanSingleton_THM = thm `;
  let p be A->bool;
  let x be A;
  assume x IN p [H1];
  assume ~(p = {x}) [H2];
  thus ? a . a IN p /\ ~(a = x)

  by H1, H2, SING_SUBSET, SUBSET_ANTISYM, SUBSET, IN_SING`;;


let Line01infinity2_THM = thm `; :: solved at 175,311,305
  let X be point;
  let l m be point_set;
  assume Line l /\ Line m[H0];
  assume ~(l = m)   [H1];
  assume X IN l /\ X IN m  [H2];
  thus l INTER m = {X}

  by  H0, H1, H2, IN_INTER, BiggerThanSingleton_THM, I1`;;

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Josef Urban]

Hi John, Bill,

> | I really want to know how strong or weak you want miz3 to be.  My
> | belief (not based on a lot of info) is that Mizar is intentionally
> | weak, partly to encourage very readable proofs and to make Mizar
> | usable for student homework, but that you have no such interest in
> | miz3 weakness.
>
> You are certainly right about Mizar's prover being intentionally weak.
> I think efficiency of proof processing may have been a (or even the)
> major factor behind this decision. With the batch processing model you
> really want the individual steps to be quick.

The batch processing is not really a problem: there are easy
directives/pragmas that switch off expensive repeated checking of
previous proofs while you work on your next theorem.

The major factor is the speed of re-factoring of a very large
mathematical library. This is being done practically daily by people
like Andrzej Trybulec, to make the library use concepts consistently,
merge formalizations done by different authors into nicely re-usable
pieces, throw out subsumed theorems when a stronger version is proved,
etc. I believe Georges Gonthier also told me that he spends really a
lot of time on refactoring his large Coq formalizations to make them
re-usable for the next parts.

If there are calls to many expensive search procedures left in the
final proof code, extensive refactoring gets unpleasant. Refactoring
MML (with over 1M calls to its own "MESON" - "by") would be a
nightmare if each took 50s. I think the solution is not to avoid
automation (as Gonthier seems to suggest), but to have good proof
translation mechanism for the expensive proofs found in 50s by ATPs
into bigger (but not too verbose) blocks of ITP code, e.g., multiple
smaller MESON calls.  And with the ATP power rising, and ATP/ITP
bridges becoming common, this seems to be one of the more important
work to be done.

Josef

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Freek, can you assure me this is not a bug (it works), ending a miz3 proof with 
a semicolon:

angle F O' D <_ang angle C O A [H3'] by H3, AngleSymmetry_THM;
seg F D <__ seg C A by H1', H2, H3', H4, EuclidPropositionI_24Help;
 qed by -, SegmentSymmetry_THM;
  end;
`;;

You suggested that I might prefer that (I do, as it simplifies your syntax), 
and I accidentally learned that miz3 accepts it.  But if you think it's a bug, 
I'll stop doing it :)

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, John!  I'd be thrilled if you included my code in the HOL Light 
distribution (miz3 dir sounds good)!  I think it would improve my paper's 
chance of being accepted.  I'll definitely write to both Hartshorne & 
Greenberg, but I'll let HOL Light finish debugging my paper first.  I think BTW 
that Hartshorne wrote a great book, but since he taught the course to 
undergraduate non-math majors, he never got real feedback about his proofs.  
Greenberg's book (which doesn't really explain the Hilbert/Euclid connection) 
is used as a math grad text so it's been torture-tested.  I certainly give 
Freek a lot of credit too, for writing a great program miz3, and for the very 
long private miz3 tutorial he gave me.  I'm really happy you ran my code, and 
that it worked!  Thanks for clarifying that you don't want miz3 to be weak:

   Yes, I don't have any similar motivation for wanting the prover to
   be weak, though requiring very low-level proofs has its place, such
   as the pedagogical application you mentioned. I do like to keep
   proofs somewhat explicit in the sense of not using many lemmas
   implicitly (which is why, for example, I don't have a larger set of
   rewrites and simplifications as the default), but I don't want to
   have to spend time manually proving things that could easily be
   blown away with decision procedures. So I suppose I want to be
   somewhat explicit about lemmas but not so much about proof methods.

I don't understand the technicalities, but may I make a suggestion?  No matter 
how powerful you make miz3, users can still put extra details in their proofs.  
The purpose of extra details is good pedagogy, so that another human can read 
the code and learn the proof.  I think my miz3 code is almost as readable as my 
paper, especially with the fancy HOL4/Isabelle-style math fonts.  If miz3 is 
really powerful, then users are on the "honor system" as to whether they really 
understand their own proofs, but math is already on the "honor system", so it's 
fine.  

   And the timeout in miz3 is presumably motivated similarly, though
   as I recall you found that a higher timeout was still productive as
   you became more experienced.

Yes, and a really important fact is that Freek tells people to increase 
timeout!   Timeout is only set to 1 because new users will make lots of simple 
mistakes, and a high timeout makes you wait for HOL Light to tell you about 
your obvious error.   Once you know what you're doing you can raise the 
timeout.   I'm using timeout := 50;; now.  Freek uses timeout := -1;; quite 
often (infinite timeout).  

I wasn't clear about my time-table yesterday.  I have 4 tasks left, in 
increasing order of difficulty:
1) finish formalizing the plane geometry parts of my 26 page paper (close to 
done)
2) port the new geometry rigor from my code to my paper (shouldn't take long, 
and then I can write to Hartshorne) 
3) finish my miz3 users guide MizTips (I must understand Freek's syntax & 
semantics lectures)
4) understand HOL (I'm reading the HOL4 Logic manual)

The last task sounds hard to me, and possibly I won't do a good job.  So if you 
want to improve miz3 for my paper, you'll have time. What I would most like you 
to look at my code and figure out why MESON is working so hard.  I have 16 
MESON solved at numbers over 200,000, but I don't think I ever ask miz3 to do 
anything as hard as the Los Logic problem, which had a MESON solved at number 
about 20,000.  My hazy guess is that I'm having a bad interaction between MESON 
(a FOL prover) and the set theory in my paper.  The first place this comes up 
is with my completely trivial rewrite of axiom B4:

let B4' = thm `;
  ! l A B C. Line l /\ ~Collinear A B C /\ 
   A NOTIN l /\ B NOTIN l /\ C NOTIN l /\ 
   (? X. X IN l /\  X IN open (A,C)) ==>
   (? Y. Y IN l /\  Y IN open (A,B)) \/ (? Y. Y IN l /\  Y IN open (B,C)) 
   by IN_Interval, B4`;;

(* 
The proof above only works because timeout is set to at least 5.
Otherwise the proof gets the miz3 error #2 inference time-out.  With
timeout set to the default value of 1, we use this proof:

let B4prime_THM = thm `;
  let l be point_set;
  let A B C be point;
  assume Line l /\ ~Collinear A B C /\ 
   A NOTIN l /\ B NOTIN l /\ C NOTIN l /\ 
   (? X. X IN l /\  X IN open (A,C)) [H1];
   thus (? Y. Y IN l /\  Y IN open (A,B)) \/ (? Y. Y IN l /\  Y IN open (B,C))

   proof
 Line l /\ ~Collinear A B C /\ 
 A NOTIN l /\ B NOTIN l /\ C NOTIN l /\ 
 (? X. X IN l /\  Between A X C) by H1, IN_Interval;
 (? Y. Y IN l /\ Between A Y B) \/ (? Y. Y IN l /\ Between B Y C) by -, 
B4;
   qed by -, IN_Interval`;;
*)

Maybe I'm the problem, and not miz3.  Maybe I need to use some HOL Light 
tactics to tell miz3 what I want it to do.  In this case, replace each Between 
P Q R in axiom B4 with the equivalent Q IN open (P,R).  

-- 
Best,
Bill 

let B4 = new_axiom
  `! l A B C. Line l /\ ~Collinear A B C /\ 
   A NOTIN l /\ B NOTIN l /\ C NOTIN l /

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Cris Perdue]

On Fri, Aug 24, 2012 at 1:28 PM, John Harrison
wrote:

>
> Hi Bill,
>
> | Thanks, John!  I'm up to Euclid's Prop I.28, so I have formalized
> | Hartshorne's result
> | http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertA
> | xiomGeometry.tar.gz Thm 10.4: All of Euclid's propositions (I.1) to
> | (I.28) except (I.1) and (I.22), can be proved in an arbitrary Hilbert
> | plane, as explained above.
>
> Congratulations --- it's a really impressive piece of work! I've just
> tried it out and it all runs for me too without a hitch. If you are
> agreeable, I think it would make sense to include it (after any final
> improvements or polishing you want to make) in the HOL Light
> distribution, either on its own or in the "miz3" directory. It's a
> very nice extended example of how the miz3 style of proof can be used.
>
> Some of the additional material like your "Miz3Tips" might be very
> useful to miz3 users too, as also might the material on Felix Breuer's
> blog (http://blog.felixbreuer.net/2012/06/11/hol.html). In general, it
> might be a good idea to make the HOL Light tutorial pages more open
> and wiki-like, which is something Colin Rowat has already suggested
> to me.
>

Putting information for beginners in a more wiki-like form that makes
contribution
by the community easier sounds great.

-Cris


>
> | So thanks for all your help, and for writing such a great program HOL
> | Light! Prop I.29 is the first time Euclid uses the parallel postulate,
> | and I think that's why Hartshorne quit there.  I'll go a little
> | farther, as no US high school geometry text does a reasonable job
> | proving the triangle sum theorem (angle sum = 180 deg), but I'll
> | finish soon.
>
> You're welcome! Indeed I think Freek deserves at least as much of the
> credit as I do, since he did most of the hard work of writing miz3,
> without which you would have been stuck with one of HOL Light's more
> cryptic proof styles. (The HOL expert style of proof was once
> parodied, I think by by Conor McBride, as "EAR_OF_BAT_TAC[]".) I'll be
> interested to see how the angle sum proof looks in axiomatic style. I
> remember being a bit surprised and disappointed at how messy the
> "vectorial" proof is that I once formalized. (See TRIANGLE_ANGLE_SUM
> in "Multivariate/geom.ml").
>
> It might be fun to contact Hartshorne himself to see if he is
> interested in your detailed formal proofs.
>
> | If you can tell me how to use use permutative rewrites in my miz3
> | code, so that ~Collinear {A, B, C} = ~Collinear {B, C, A} =
> | ~Collinear {C, B, A} etc, I'll code it up, and it will make my
> | code a little cleaner.  I bet you're especially busy with the new
> | ocaml release, and if we don't fix this, that's fine.
>
> I'll take a look at your code and see if it would be easy-ish to
> make such a cleanup.
>
> | I didn't have any serious comment about the different versions of
> | HOL.  All of you are using HOL for real world projects where you
> | really have to believe the code works, and I bet everyone sensibly
> | says, "I'm going to use my code, which I trust."
>
> Yes, and even though I trust other code, one gets very attached to
> one's own baby, as you can imagine.
>
> | I really want to know how strong or weak you want miz3 to be.  My
> | belief (not based on a lot of info) is that Mizar is intentionally
> | weak, partly to encourage very readable proofs and to make Mizar
> | usable for student homework, but that you have no such interest in
> | miz3 weakness.
>
> You are certainly right about Mizar's prover being intentionally weak.
> I think efficiency of proof processing may have been a (or even the)
> major factor behind this decision. With the batch processing model you
> really want the individual steps to be quick. And the timeout in miz3
> is presumably motivated similarly, though as I recall you found that
> a higher timeout was still productive as you became more experienced.
>
> Yes, I don't have any similar motivation for wanting the prover to be
> weak, though requiring very low-level proofs has its place, such as
> the pedagogical application you mentioned. I do like to keep proofs
> somewhat explicit in the sense of not using many lemmas implicitly
> (which is why, for example, I don't have a larger set of rewrites and
> simplifications as the default), but I don't want to have to spend
> time manually proving things that could easily be blown away with
> decision procedures. So I suppose I want to be somewhat explicit about
> lemmas but not so much about proof methods.
>
> | MESON is pretty powerful! If you had a more powerful FOL prover than
> | MESON, or a compatible set-theory prover, I think you use such provers
> | in holby.ml as well.  Your purple book seemed to stress that we should
> | be combining the procedural and declarative approaches, and that
> | doesn't indicate a desire to weaken the declarative approach.
>
> Yes, there is lots of scope for improving such provers, and I think it
> coul

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

| Thanks, John!  I'm up to Euclid's Prop I.28, so I have formalized
| Hartshorne's result
| http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertA
| xiomGeometry.tar.gz Thm 10.4: All of Euclid's propositions (I.1) to
| (I.28) except (I.1) and (I.22), can be proved in an arbitrary Hilbert
| plane, as explained above.

Congratulations --- it's a really impressive piece of work! I've just
tried it out and it all runs for me too without a hitch. If you are
agreeable, I think it would make sense to include it (after any final
improvements or polishing you want to make) in the HOL Light
distribution, either on its own or in the "miz3" directory. It's a
very nice extended example of how the miz3 style of proof can be used.

Some of the additional material like your "Miz3Tips" might be very
useful to miz3 users too, as also might the material on Felix Breuer's
blog (http://blog.felixbreuer.net/2012/06/11/hol.html). In general, it
might be a good idea to make the HOL Light tutorial pages more open
and wiki-like, which is something Colin Rowat has already suggested
to me.

| So thanks for all your help, and for writing such a great program HOL
| Light! Prop I.29 is the first time Euclid uses the parallel postulate,
| and I think that's why Hartshorne quit there.  I'll go a little
| farther, as no US high school geometry text does a reasonable job
| proving the triangle sum theorem (angle sum = 180 deg), but I'll
| finish soon.

You're welcome! Indeed I think Freek deserves at least as much of the
credit as I do, since he did most of the hard work of writing miz3,
without which you would have been stuck with one of HOL Light's more
cryptic proof styles. (The HOL expert style of proof was once
parodied, I think by by Conor McBride, as "EAR_OF_BAT_TAC[]".) I'll be
interested to see how the angle sum proof looks in axiomatic style. I
remember being a bit surprised and disappointed at how messy the
"vectorial" proof is that I once formalized. (See TRIANGLE_ANGLE_SUM
in "Multivariate/geom.ml").

It might be fun to contact Hartshorne himself to see if he is
interested in your detailed formal proofs.

| If you can tell me how to use use permutative rewrites in my miz3
| code, so that ~Collinear {A, B, C} = ~Collinear {B, C, A} =
| ~Collinear {C, B, A} etc, I'll code it up, and it will make my
| code a little cleaner.  I bet you're especially busy with the new
| ocaml release, and if we don't fix this, that's fine.

I'll take a look at your code and see if it would be easy-ish to
make such a cleanup.

| I didn't have any serious comment about the different versions of
| HOL.  All of you are using HOL for real world projects where you
| really have to believe the code works, and I bet everyone sensibly
| says, "I'm going to use my code, which I trust."

Yes, and even though I trust other code, one gets very attached to
one's own baby, as you can imagine.

| I really want to know how strong or weak you want miz3 to be.  My
| belief (not based on a lot of info) is that Mizar is intentionally
| weak, partly to encourage very readable proofs and to make Mizar
| usable for student homework, but that you have no such interest in
| miz3 weakness.

You are certainly right about Mizar's prover being intentionally weak.
I think efficiency of proof processing may have been a (or even the)
major factor behind this decision. With the batch processing model you
really want the individual steps to be quick. And the timeout in miz3
is presumably motivated similarly, though as I recall you found that
a higher timeout was still productive as you became more experienced.

Yes, I don't have any similar motivation for wanting the prover to be
weak, though requiring very low-level proofs has its place, such as
the pedagogical application you mentioned. I do like to keep proofs
somewhat explicit in the sense of not using many lemmas implicitly
(which is why, for example, I don't have a larger set of rewrites and
simplifications as the default), but I don't want to have to spend
time manually proving things that could easily be blown away with
decision procedures. So I suppose I want to be somewhat explicit about
lemmas but not so much about proof methods.

| MESON is pretty powerful! If you had a more powerful FOL prover than
| MESON, or a compatible set-theory prover, I think you use such provers
| in holby.ml as well.  Your purple book seemed to stress that we should
| be combining the procedural and declarative approaches, and that
| doesn't indicate a desire to weaken the declarative approach.

Yes, there is lots of scope for improving such provers, and I think it
could raise the level of interaction in miz3 to have a more powerful
prover. Ideally one would want a smooth integration of pure logic, set
theory, algebra and arithmetical theories, but that's still a research
challenge. Still, we know enough to make it much more powerful than
the current placeholder, and modern FOL provers do sometimes manage
to do more th

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, John!  I'm up to Euclid's Prop I.28, so I have formalized Hartshorne's 
result
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
Thm 10.4:
All of Euclid's propositions (I.1) to (I.28) except (I.1) and (I.22), can be 
proved in an arbitrary Hilbert plane, as explained above. 

So thanks for all your help, and for writing such a great program HOL Light!  
Prop I.29 is the first time Euclid uses the parallel postulate, and I think 
that's why Hartshorne quit there.  I'll go a little farther, as no US high 
school geometry text does a reasonable job proving the triangle sum theorem 
(angle sum = 180 deg), but I'll finish soon.  If you can tell me how to use use 
permutative rewrites in my miz3 code, so that 
~Collinear {A, B, C} = ~Collinear {B, C, A}  = ~Collinear {C, B, A} 
etc, I'll code it up, and it will make my code a little cleaner.  I bet you're 
especially busy with the new ocaml release, and if we don't fix this, that's 
fine.  I didn't have any serious comment about the different versions of HOL.  
All of you are using HOL for real world projects where you really have to 
believe the code works, and I bet everyone sensibly says, "I'm going to use my 
code, which I trust."

I really want to know how strong or weak you want miz3 to be.  My belief (not 
based on a lot of info) is that Mizar is intentionally weak, partly to 
encourage very readable proofs and to make Mizar usable for student homework, 
but that you have no such interest in miz3 weakness.  I have only two pieces of 
evidence about your intentions.  Your file Examples/holby.ml starts 

(* = *)
(* A HOL "by" tactic, doing Mizar-like things, trying something that is  *)
(* sufficient for HOL's basic rules, trying a few other things like  *)
(* arithmetic, and finally if all else fails using MESON_TAC[].  *)
(* = *)

MESON is pretty powerful! If you had a more powerful FOL prover than MESON, or 
a compatible set-theory prover, I think you use such provers in holby.ml as 
well.  Your purple book seemed to stress that we should be combining the 
procedural and declarative approaches, and that doesn't indicate a desire to 
weaken the declarative approach.  

My opinion about weakness has changed drastically.  Initially I was counting on 
miz3 to be weak to make sure I wasn't taking big leaps, and to police student 
homework.  But a long discussion here convinced me (Michael mostly) that this 
weakness isn't a good idea.  I now think taking big leaps is fine, and if I'm 
too dumb to spot big leaps in either my code in a students, uh, I'm in bad 
shape, and I shouldn't be counting on the program to bail me out.  One of the 
things which changed my mind was a discussion with Cris and Rob about Los's 
Logic problem which you write about on p 36 of your tutorial, writing "The 
machine proves this a lot faster than I could."  I couldn't prove it at all.  
But Rob wrote up a short mathematical proof of Los's Logic result, which I 
easily coded in miz3 (code for Rob's original proof below) and I decided that 
it's OK for MESON to perform such leaps in my code.  

-- 
Best,
Bill 

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;; 

let RobProof2LosLogic_THM = thm `;
  let P Q be A->A->bool;
  assume ! x y z. P x y /\ P y z ==> P x z [Ptrans];
  assume ! x y z. Q x y /\ Q y z ==> Q x z [Qtrans];
  assume !x y. P x y ==> P y x[Psym];
  assume !x y. P x y \/ Q x y[PunionQ];
  thus (!x y. P x y) \/ (!x y. Q x y)

  proof
assume ~(!x y. P x y);
consider a b such that 
~P a b  /\ ~P b a [notPab] by -, Psym;
Q a b /\ Q b a [Qab] by -, Psym, PunionQ;
!x y. Q x y
proof
  let x y be A;
  cases;
  suppose P x a /\ P b y [PxyPby];
~P x y
proof
  assume P x y [Con];
  P a x /\ P y b by PxyPby, Psym;
  P a b by -, Con, Ptrans;
qed by -, notPab;
Q x y by -, PunionQ;
  qed by -;
  suppose ~P x a /\ ~P b y;
Q x a /\ Q b y by -, PunionQ;
  qed by -, Qab, Qtrans;
  suppose P x a /\ ~P b y [Pxy_notPby];
~P x b
proof
  assume P x b;
P a b by -, Pxy_notPby, Psym, Ptrans;
  qed by -, notPab;
Q x b /\ Q b y by -, Pxy_notPby, PunionQ;
  qed by -, Qtrans;
  suppose ~P x a /\ P b y;
P y b /\ ~P a x [Pyb_notPax] by -, Psym;
~P y a
proof
  assume P y a;
  P a b by -, Psym, Pyb_notPax, Ptrans;
qed by -, notPab;
Q x a /\ Q a y by Pyb_notPax, -, Psym, PunionQ;
  qed by -, Qtrans;
end;
  qed by -`;;

--
Live Security Virtual Conference
Exclusive live event will cover all the way

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

| Thanks!  But the OP (me) really was asking a different question:  why
| aren't you, Konrad, Rob and Michael all working on the same program,
| which you could maybe call HOL4LightPower?  Wouldn't that increase
| productivity?  John, you seem to be on the extreme Math end of CS, and
| I like that a lot, but Konrad, Rob and Michael are making a real good
| impression on me as well.  I think I'm missing something about
| fundamental programming incompatibilities, or different aims.

I suppose the division arose from differences in emphasis (e.g.
ProofPower attached more importance to software engineering rigor and
HOL Light to conceptual simplicity), or because of preferences in
programming languages (SML versus CAML), or relatively minor things
like that.

I don't think there is, or was, a real difference in goals as far as
verification vs. mathematics or theory vs. practice is concerned. It's
just that people happened to use one tool or the other for particular
things, which tends to be a bit self-reinforcing since the
availability of relevant libraries etc. attracts others to the same
tool.

Perhaps projects like OpenTheory or the various schemes for proof
import and export will at least allow better interoperability between
the tools, even if we don't have a single unified system.

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

| I would tend to think your  focused approach to permutations isn't general
| enough, but I'm no expert.  I did read some of your book, the Mizar-like
| section, and it seemed to me that you said something really important:
| neither of the following approaches is very good:
|
| 1) get the computer to go prove the theorem;
| 2) tell the the computer exactly how to go prove the theorem;
| and the winning strategy is to combine (1) & (2).

I agree absolutely that focusing on the special case of simple
permutation of arguments is unsatisfyingly specialized. I suspect,
however, that if you go too far beyond it then things may well become
undecidable. So even if one wants (1), it might not be feasible,
though it would be very interesting to investigate the boundary and
perhaps find interesting decidable subsets or useful heuristics.

HOL Light, in common with some other proof assistants, has a few
tricks for permutative rewrites so that things can be "normalized" by
rewriting with suitable theorems, e.g.

  let trivial_example = prove
   (`{a,c,d,d,a,b} = {d,a,b,c}`,
REWRITE_TAC[INSERT_AC]);;

This idea goes back at least to Boyer and Moore, and there is a nice
paper "Ordered Rewriting and Confluence" by Ursula Martin and Tobias
Nipkow that shows it off on many examples. However, as soon as you
combine even this kind of simple permutative reasoning, let alone
general set equivalence, with quantifier instantiation, matters are
substantially more complicated. Konrad Slind's paper "AC unification
in hol90" describes a HOL implementation of associative-commutative
unification, which is one approach to such problems.

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Ramana Kumar]

On Thu, Aug 23, 2012 at 5:26 AM, Bill Richter  wrote:

> Thanks!  But the OP (me) really was asking a different question:  why
> aren't you, Konrad, Rob and Michael all working on the same program, which
> you could maybe call HOL4LightPower?  Wouldn't that increase productivity?
>  John, you seem to be on the extreme Math end of CS, and I like that a lot,
> but Konrad, Rob and Michael are making a real good impression on me as
> well.  I think I'm missing something about fundamental programming
> incompatibilities, or different aims.  Rob said that HOL Light is about
> proving theorems (which is why I use it, I think), and HOL4 was about
> hardware and software verification.


My slides from the last ITP conference are somewhat relevant:
http://xrchz.net/sozi.svg. Hopefully not impossibly cryptic without a
speaker.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, thanks for explaining #trace SET_RULE;; and for your long interesting 
response.

   A crude approach would be simply to use SET_TAC in place of
   MESON_TAC [...] However, I would like to do things a bit more
   carefully [...] this would make a good excuse. I will think about
   it a bit more.

That sounds fabulous, and not something we should tie my paper to.  I realized 
that a good part of my problem (excessive use of the 3-fold symmetry of 
Collinear A B C) was caused by loading up my theorem statements with extra 
assumptions  because of needless error checking, and I'm fixing that now.  
Right now I'm just doing that and reading the HOL4 Logic manual, which seems 
very rigorous but could use more introductory notes.

   those like myself have been using HOL for so long that we've lost
   track of how baffling some of it is to the uninitiated.

Thanks!

   It's very encouraging to hear that HOL Light helped you to debug
   your own explicit proofs. 

Thanks, and it would definitely motivate folks to read my paper, knowing that 
it's already been debugged by HOL Light , or at least it will be, after my 
forthcoming massive miz3-induced rewrite.  

   In my experience, proofs at that level are very hard to get right
   by hand, which may be why few others have tried to make the proofs
   as explicit as you did. After all, you might expect this to be
   well-trodden ground given the long history of axiomatic geometry,
   yet it seems that pretty much everyone including Hartshorne has
   been content with vaguer sketches, accurate or not, of what could
   be done in principle.

That sounds great, but there's an important human angle here too.  I haven't 
talked to anyone about my proofs except for my 14yo son, who caught many of my 
errors.  If you get a lot of humans working in the same subject, they'll shake 
out a lot of bugs.  But maybe the reason why Hartshorne's vaguer sketches 
suffice is that the real powerhouses here, the high school students, aren't 
working on real axiomatic geometry.  And maybe that's just because we didn't 
have a way, until now, for the students to code up their proofs!

   Yes, that would obviously be a very useful thing. It should be easy
   enough to code up. I am tempted to call it "mizuse" but that might
   be misunderstood.

Excellent!  And I like mizuse! It would be especially good if Freek would write 
a new version, and then you could call it "miz4use", miz for our use!  Thanks 
for the long explanation of sets vs predicates, and that sets as
predicates is due to you.   I'm really more worried about HOL as a theory, a 
foundationalization of math more like Russell-Whitehead-Church than ZFC FOL.

   You can always tell the abstractions apart because they have at
   least one vertical bar as in {f x | P x} (sometimes two bars if you
   need to disambiguate the intended bound variables).
   [...] Generally the approach is to prettyprint certain "standard" forms in
   a special way, where it seems likely to be intuitive to the user. 

Ah, so I was concentrating on the less meaningful curly braces {...}.  Thanks. 

a HOL4 precursor called hol90 that was developed by Konrad Slind
   contemporaneously with ProofPower, and this evolved via hol98 into
   HOL4 some years later in the hands of Michael Norrish together with
   Konrad, as well as forming the main starting point for HOL Light.

Thanks!  But the OP (me) really was asking a different question:  why aren't 
you, Konrad, Rob and Michael all working on the same program, which you could 
maybe call HOL4LightPower?  Wouldn't that increase productivity?  John, you 
seem to be on the extreme Math end of CS, and I like that a lot, but Konrad, 
Rob and Michael are making a real good impression on me as well.  I think I'm 
missing something about fundamental programming incompatibilities, or different 
aims.  Rob said that HOL Light is about proving theorems (which is why I use 
it, I think), and HOL4 was about hardware and software verification.  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John and Ramana, thanks again!  It turns out that my problem was entirely 
caused by my abstraction definition union replacement for UNION.  This now 
works (as part of 4200 lines of code formalizing Euclid up to Prop I.26, the 
Alternate Interior Angles thm), since I switched back to UNION:

let SegmentSymmetry_THM = thm `;
  let A B be point;
  thus seg A B = seg B A
 by Segment_DEF, IntervalSymmetry_THM, SET_RULE`;;

[...] solved at 173
val SegmentSymmetry_THM : thm = |- !A B. seg A B = seg B A

Below is an actual report (not of a bug) that indicates SET_RULE gets confused 
by anything that's not defined in sets.ml.  Everything works with UNION, but 
nothing works with union.  John wrote 

   Although [SET_RULE] can certainly prove `{A,B,C} = {B,A,C}` etc. as
   a standalone goal, SET_RULE would not, for example, give you even
   such simple generalizations as `P {A,B,C} ==> P {B,A,C}`. 

I think my report below is an example of this.

   It would be an interesting (and not necessarily easy) project to
   extend its abilities like this. But it might be much easier to take
   a more focused approach to dealing with this kind of permutation
   (e.g. something akin to Brand's transformation, which is explained
   a bit in my book).

Interesting!  I think we're talking about general directions of improving miz3. 
 My hazy idea is that your holby.ml prover for miz3 "by" justifications ought 
to do for sets everything that's analogous to what MESON already does for FOL.  
I would tend to think your  focused approach to permutations isn't general 
enough, but I'm no expert.  I did read some of your book, the Mizar-like 
section, and it seemed to me that you said something really important: neither 
of the following approaches is very good:
1) get the computer to go prove the theorem;
2) tell the the computer exactly how to go prove the theorem;
and the winning strategy is to combine (1) & (2).  I liked that a lot, even 
though right now I'm working almost entirely in (2), and I think it follows 
logically that you want miz3 to be as powerful as possible, while the Mizar 
folks seemed to desire Mizar to be relatively weak. If you could comment, it 
might be helpful, as this matter came up while you were gone. 

-- 
Best,
Bill 

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;; 
timeout := 50;;

SET_RULE `X = Y ==> {a, b} UNION X  = {b, a} UNION Y `;;

let DoubletonSymmetry_THM = thm `;
  let a b be A;
  thus {a, b}  = {b, a} 
  by SET_RULE`;;

let DoubletonXSymmetry_THM = thm `;
  let a b be A;
  let X be A->bool;
  thus {a, b} UNION X = {b, a} UNION X
  by SET_RULE`;;

let DoubletonPlusSymmetry_THM = thm `;
  let a b be A;
  let X Y be A->bool;
  assume X = Y [H1];
  thus {a, b} UNION X = {b, a} UNION Y
  by SET_RULE,  H1`;;

parse_as_infix("union",(16, "right"));;

let union = new_definition
  `∀ s t:A->bool. s union t = λ x. x ∈ s ∨ x ∈ t`;;

SET_RULE `X = Y ==> {a, b} union X  = {b, a} union Y `;;

let DoubletonXunionSymmetry_THM = thm `;
  let a b be A;
  let X be A->bool;
  thus {a, b} union X = {b, a} union X
  by SET_RULE`;;

let DoubletonPlusunionSymmetry_THM = thm `;
  let a b be A;
  let X Y be A->bool;
  assume X = Y [H1];
  thus {a, b} union X = {b, a} union Y
  by SET_RULE,  H1`;;

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thank Ramana and John, and how dumb of me!  Yes, your fix works fine:

horizon := 0;; 
let DoubletonPlusSymmetry_THM = thm `;
  let a b be A;
  let X Y be A->bool;
  assume X = Y [H1];
  thus {a, b} UNION X = {b, a} UNION Y
  by SET_RULE, H1`;;

So I don't have an explanation of why my miz3 code doesn't work:

let Segment_DEF = new_definition
  `seg A B = {A, B} union open (A,B)`;;

IntervalSymmetry_THM |- ∀ A B. open (A,B) = open (B,A)

let SegmentSymmetry_THM = thm `;
  let A B be point;
  thus seg A B = seg B A
 by Segment_DEF, IntervalSymmetry_THM, SET_RULE`;;

IntervalSymmetry_THM is like the hypothesis H1, and Segment_DEF turns seg A B = 
seg B A into something like 
{a, b} UNION X = {b, a} UNION Y.  But I don't have a short distilled bug report 
for it. 

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Rob wrote:

| > Why are there so many HOLs, HOL Light, Hol4, Holzero?
|
| That's a very long story. HOL4 and ProofPower came first in the early
| 90s as a result of roughly simultaneous efforts in academia (HOL4) and
| industry (ProofPower) to port Mike Gordon's original Classic HOL onto
| Standard ML. John wrote HOL Light a few years later, see
| http://www.cl.cam.ac.uk/~jrh13/papers/holright.html for some of his
| motivation. Holzero is much more recent work by Mark Adams and Mark's
| website explains his rationale. There is also HOL Omega by Peter
| Homeier, which is an extension of HOL4 to support quantification over
| types.

Well, to be strictly accurate at the cost of an even longer story, it
was a HOL4 precursor called hol90 that was developed by Konrad Slind
contemporaneously with ProofPower, and this evolved via hol98 into
HOL4 some years later in the hands of Michael Norrish together with
Konrad, as well as forming the main starting point for HOL Light. I
have a little slide that I sometimes use in talks showing my picture
of the HOL family tree. See, for example, slide 30 of the following:

  http://www.cl.cam.ac.uk/~jrh13/slides/popl-28jan11/slides.pdf

I would also add HOL2P (http://cswww.essex.ac.uk/staff/norbert/hol2p/)
to the list of broadly upward-compatible extensions to the HOL logic.
>From an implementation point of view, HOL2P is a HOL Light extension
while HOL-Omega is a HOL4 extension. From a logical point of view,
HOL-Omega is, as I understand it, a further generalization of HOL2P,
which is itself a generalization of HOL.

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

| let DoubletonPlusSymmetry_THM = thm `;
|   let a b be A;
|   let X Y be A->bool;
|   assume X = Y;
|   thus {a, b} UNION X = {b, a} UNION Y
|   by SET_RULE`;;

I think Ramana correctly diagnosed the problem, namely that the X = Y
assumption is not being implicitly used. If you change "horizon := 0"
to "horizon := 1" then it works. Though you probably wouldn't want to
do this globally, since you want to keep your proofs explicit and not
allow implicit assumptions.

One useful way of debugging such things is to turn on OCaml's tracing
to see exactly what is getting passed to the inference rule. So for
example, if you do the following before the above script you can see
what SET_RULE is trying to prove in each case

  #trace SET_RULE;;

| I know you're real busy right now, and I can't argue this is high
| priority, but I think it would be nice for miz3 to have a good
| set-theory prover to go along with its good FOL prover MESON.  I
| don't know exactly what this set-theory prover ought to prove, but
| I figure it should prove result analogous to what MESON already
| proves.

Yes, this would clearly be a useful thing to do. A crude approach
would be simply to use SET_TAC in place of MESON_TAC in the
justification code. All that SET_TAC really does is expand some
set-theoretic definitions systematically and then call MESON, as you
can see from the code:

  let SET_TAC =
let PRESET_TAC =
  POP_ASSUM_LIST(K ALL_TAC) THEN REPEAT COND_CASES_TAC THEN
  REWRITE_TAC[EXTENSION; SUBSET; PSUBSET; DISJOINT; SING] THEN
  REWRITE_TAC[NOT_IN_EMPTY; IN_UNIV; IN_UNION; IN_INTER; IN_DIFF; IN_INSERT;
  IN_DELETE; IN_REST; IN_INTERS; IN_UNIONS; IN_IMAGE;
  IN_ELIM_THM; IN] in
fun ths ->
  (if ths = [] then ALL_TAC else MP_TAC(end_itlist CONJ ths)) THEN
  PRESET_TAC THEN
  MESON_TAC[];;

  let SET_RULE tm = prove(tm,SET_TAC[]);;

However, I would like to do things a bit more carefully since this
preprocessing can occasionally hinder MESON as well as helping it.
Indeed, I have a few problems with SET_TAC that I would like to fix
(e.g. the first rewrite sometimes expands things too eagerly in the
case of sets of sets), and this would make a good excuse. I will think
about it a bit more.

I should also say that SET_RULE/SET_TAC, while tremendously useful for
generating trivial but tedious-to-prove little facts of set theory, may
not quite do all you wanted originally, making the built-in
justification insensitive to ordering in terms like `Collinear {A,B,C}`.
Although it can certainly prove `{A,B,C} = {B,A,C}` etc. as a
standalone goal, SET_RULE would not, for example, give you even such
simple generalizations as `P {A,B,C} ==> P {B,A,C}`. It would be an
interesting (and not necessarily easy) project to extend its abilities
like this. But it might be much easier to take a more focused approach
to dealing with this kind of permutation (e.g. something akin to
Brand's transformation, which is explained a bit in my book).

I'm a bit late to the party with recent discussions, but here are
a few other comments:

| The only reason I'm using union is to spare my readers the complicated
| and wonderful things that HOL folks have figured out, such as
| IN_ELIM_THM. But SET_RULE (from sets.ml) uses IN_ELIM_THM!  The only
| problem I'm worrying about here is whether this short simple
| beautiful HOL Light isn't simple enough for my hotshot Math PhDs:

That is of course quite possible: those like myself have been using
HOL for so long that we've lost track of how baffling some of it is
to the uninitiated. Though you might still be able to make the case
that it would suffice to prove equivalence of the definition to a
more transparent one, rather than actually change the definition.
By analogy, whether you define "polytope" as "bounded polyhedron"
or "convex hull of a finite set" isn't that important provided you
can derive the other possible definition as a theorem.

| Anyway, it was clear to me that Hartshorne skipped a lot of steps in
| his proofs that folks can't fill in if they're not really serious
| about math, and I filled in many of these steps in my paper
| http://www.math.northwestern.edu/~richter/hilbert.pdf, which is now
| badly in need of revision because of all the steps HOL Light pointed
| out that I skipped and bungled!

It's very encouraging to hear that HOL Light helped you to debug your
own explicit proofs. In my experience, proofs at that level are very
hard to get right by hand, which may be why few others have tried to
make the proofs as explicit as you did. After all, you might expect
this to be well-trodden ground given the long history of axiomatic
geometry, yet it seems that pretty much everyone including Hartshorne
has been content with vaguer sketches, accurate or not, of what could
be done in principle.

| I can think of other miz3 problems that seem a lot more pressing that
| set notations, like being able to use #use ".ml";; I'm
| guessing

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Ramana Kumar]

On Wed, Aug 22, 2012 at 4:39 AM, Bill Richter  wrote:

> John, I'm still excited by your SET_RULE, but I ran into a problem that
> maybe is a serious miz3/set problem, unlike miz3's incomplete ability to
> prove abstractions and sets were equal.  I distilled my problem down to
> this example, where the first three results are fine, but the last
> (DoubletonPlusSymmetry) gets a #1 inference error:
>
> #load "unix.cma";;
> loadt "miz3/miz3.ml";;
> horizon := 0;;
> timeout := 50;;
>
> SET_RULE `X = Y ==> {a, b} UNION X  = {b, a} UNION Y `;;
>
> let DoubletonSymmetry_THM = thm `;
>   let a b be A;
>   thus {a, b}  = {b, a}
>   by SET_RULE`;;
>
> let DoubletonXSymmetry_THM = thm `;
>   let a b be A;
>   let X be A->bool;
>   thus {a, b} UNION X = {b, a} UNION X
>   by SET_RULE`;;
>
> let DoubletonPlusSymmetry_THM = thm `;
>   let a b be A;
>   let X Y be A->bool;
>   assume X = Y;
>   thus {a, b} UNION X = {b, a} UNION Y
>   by SET_RULE`;;
>


I don't know anything about SET_RULE, but does it pay attention to your
assumptions ("assume X=Y")?
That's the main difference between this proof that fails and what looks
equivalent (line starting "SET_RULE") above.


>
> I can't see any mistake I'm making.  Maybe I should say how this actually
> came up.  I have defs & thms
> let Segment_DEF = new_definition
>   `seg A B = {A, B} union open (A,B)`;;
> IntervalSymmetry_THM |- ∀ A B. open (A,B) = open (B,A)
> DoubletonSymmetry_THM |- ∀ A B. {A, B} = {B, A}
> SegmentSymmetry_THM |- ∀ A B. seg A B = seg B A
>
> and the proof of the last is
> let SegmentSymmetry_THM = thm `;
>   let A B be point;
>   thus seg A B = seg B A
>  by Segment_DEF, IntervalSymmetry_THM, DoubletonSymmetry_THM`;;
>
> and I thought I should be able to replace DoubletonSymmetry_THM by
> SET_RULE, and it did not work:
> let SegmentSymmetry_THM = thm `;
>   let A B be point;
>   thus seg A B = seg B A
>  by Segment_DEF, IntervalSymmetry_THM, SET_RULE`;;
>
> I get a #1 inference error.  I know you're real busy right now, and I
> can't argue this is high priority, but I think it would be nice for miz3 to
> have a good set-theory prover to go along with its good FOL prover MESON.
>  I don't know exactly what this set-theory prover ought to prove, but I
> figure it should prove result analogous to what MESON already proves.
>
> My request that you install SET_RULE in miz3 was illogical, as later in my
> post I said I didn't want to use SET_RULE because it was as hard as
> IN_ELIM_THM.  But heck, I was really excited to see SET_RULE  give a
> stunning 1-line proof to replace my long and boring proof
>
> let DoubletonSymmetry_THM = thm `;
>   let x y be A;
>   thus {x, y} = {y, x}
>
>   proof
> {x, y} = x  INSERT {y} /\ {y, x} = y INSERT {x} [defDoubleton];
> ! P. P IN {x, y} <=> P = x \/ P = y [defxy] by defDoubleton,
> IN_INSERT, IN_SING;
> ! P. P IN {y, x} <=> P = x \/ P = y by defDoubleton, IN_INSERT,
> IN_SING;
>   qed by -, defxy, EXTENSION`;;
>
> Eventually I want to discuss HOL with you, as your HOL Light documentation
> explains very little about it.  Michael, Konrad, Rob, Ramana, Mark and Cris
> helped me a lot, but I have reading to do.  Let me summarize:
>
> Tom Hales in his Notices article shows that he really understand HOL, but
> he doesn't explain it to novices.  I'm trying to read Michael & Konrad HOL4
> Logic manual, which they assure me holds for HOL Light as well.  Rob had a
> great slogan, that HOL would be better named "polymorphic typed set theory."
>
> Michael assured me that my first line of code, due to you (thanks again!)
> new_type("point",0);;
> means that `point' is the name of a set which right now we know nothing
> about it, but the axioms, also largely due to you (thanks again!), describe
> more and more precisely.  So the set `point' is what's often called a
> Hilbert plane.  Furthermore, Michael agreed, my next lines
> new_type_abbrev("point_set",`:point->bool`);;
> new_constant("Line",`:point_set->bool`);;
> means there is a function Line: P(point) ---> bool which is supposed to
> tell if a subset of our Hilbert plane `point' is actually a line.  Again,
> the axioms describe (or constrain) the function Line.
>
> I think there's a lot of mutual distrust between the fields of Math and
> CS, and I'm hoping to help improve matters, but I'm maybe as bad as anyone,
> as I had sneered at the whole idea of HOL, thinking it's obvious they're
> just doing ZFC, why can't they explain this clearly.  I'm now quite
> embarrassed by my old attitude, as it seems that HOL grows out of
> Russell-Whitehead's initial foundationalizing of math, and profited from
> Church's improvements in typed LC.  I had no idea anything like this was
> going on, and I think I'm expert in LC!  Math Logic (which I think is quite
> close to CS) isn't taken seriously in Math depts, but I've been exposed to
> Math Logic, but head nothing about Russell-Whitehead or Church math
> foundations.
>

I would love to see some

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, I'm still excited by your SET_RULE, but I ran into a problem that maybe 
is a serious miz3/set problem, unlike miz3's incomplete ability to prove 
abstractions and sets were equal.  I distilled my problem down to this example, 
where the first three results are fine, but the last (DoubletonPlusSymmetry) 
gets a #1 inference error:

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;; 
timeout := 50;;

SET_RULE `X = Y ==> {a, b} UNION X  = {b, a} UNION Y `;;

let DoubletonSymmetry_THM = thm `;
  let a b be A;
  thus {a, b}  = {b, a} 
  by SET_RULE`;;

let DoubletonXSymmetry_THM = thm `;
  let a b be A;
  let X be A->bool;
  thus {a, b} UNION X = {b, a} UNION X
  by SET_RULE`;;

let DoubletonPlusSymmetry_THM = thm `;
  let a b be A;
  let X Y be A->bool;
  assume X = Y;
  thus {a, b} UNION X = {b, a} UNION Y
  by SET_RULE`;;

I can't see any mistake I'm making.  Maybe I should say how this actually came 
up.  I have defs & thms 
let Segment_DEF = new_definition
  `seg A B = {A, B} union open (A,B)`;;
IntervalSymmetry_THM |- ∀ A B. open (A,B) = open (B,A)
DoubletonSymmetry_THM |- ∀ A B. {A, B} = {B, A}
SegmentSymmetry_THM |- ∀ A B. seg A B = seg B A

and the proof of the last is 
let SegmentSymmetry_THM = thm `;
  let A B be point;
  thus seg A B = seg B A
 by Segment_DEF, IntervalSymmetry_THM, DoubletonSymmetry_THM`;;

and I thought I should be able to replace DoubletonSymmetry_THM by SET_RULE, 
and it did not work:
let SegmentSymmetry_THM = thm `;
  let A B be point;
  thus seg A B = seg B A
 by Segment_DEF, IntervalSymmetry_THM, SET_RULE`;;

I get a #1 inference error.  I know you're real busy right now, and I can't 
argue this is high priority, but I think it would be nice for miz3 to have a 
good set-theory prover to go along with its good FOL prover MESON.  I don't 
know exactly what this set-theory prover ought to prove, but I figure it should 
prove result analogous to what MESON already proves.

My request that you install SET_RULE in miz3 was illogical, as later in my post 
I said I didn't want to use SET_RULE because it was as hard as IN_ELIM_THM.  
But heck, I was really excited to see SET_RULE  give a stunning 1-line proof to 
replace my long and boring proof 

let DoubletonSymmetry_THM = thm `;
  let x y be A;
  thus {x, y} = {y, x}

  proof
{x, y} = x  INSERT {y} /\ {y, x} = y INSERT {x} [defDoubleton];
! P. P IN {x, y} <=> P = x \/ P = y [defxy] by defDoubleton, IN_INSERT, 
IN_SING;
! P. P IN {y, x} <=> P = x \/ P = y by defDoubleton, IN_INSERT, 
IN_SING; 
  qed by -, defxy, EXTENSION`;;

Eventually I want to discuss HOL with you, as your HOL Light documentation 
explains very little about it.  Michael, Konrad, Rob, Ramana, Mark and Cris 
helped me a lot, but I have reading to do.  Let me summarize:

Tom Hales in his Notices article shows that he really understand HOL, but he 
doesn't explain it to novices.  I'm trying to read Michael & Konrad HOL4 Logic 
manual, which they assure me holds for HOL Light as well.  Rob had a great 
slogan, that HOL would be better named "polymorphic typed set theory."  

Michael assured me that my first line of code, due to you (thanks again!) 
new_type("point",0);;
means that `point' is the name of a set which right now we know nothing about 
it, but the axioms, also largely due to you (thanks again!), describe more and 
more precisely.  So the set `point' is what's often called a Hilbert plane.  
Furthermore, Michael agreed, my next lines 
new_type_abbrev("point_set",`:point->bool`);;
new_constant("Line",`:point_set->bool`);;
means there is a function Line: P(point) ---> bool which is supposed to tell if 
a subset of our Hilbert plane `point' is actually a line.  Again, the axioms 
describe (or constrain) the function Line.

I think there's a lot of mutual distrust between the fields of Math and CS, and 
I'm hoping to help improve matters, but I'm maybe as bad as anyone, as I had 
sneered at the whole idea of HOL, thinking it's obvious they're just doing ZFC, 
why can't they explain this clearly.  I'm now quite embarrassed by my old 
attitude, as it seems that HOL grows out of Russell-Whitehead's initial 
foundationalizing of math, and profited from Church's improvements in typed LC. 
 I had no idea anything like this was going on, and I think I'm expert in LC!  
Math Logic (which I think is quite close to CS) isn't taken seriously in Math 
depts, but I've been exposed to Math Logic, but head nothing about 
Russell-Whitehead or Church math foundations.  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

John, can you make SET_RULE part of the miz3 "by" justification?   What I just 
wrote about Collinear {A, B, C} doesn't yet make sense, because miz3 does not 
know that 
{A, B, C} = {A, C, B} = {B, A, C} = {B, C, A} = {C, A, B} = {C, B, A}.
At least, I had to work to prove a simpler result that's analogous to what 
MESON does immediately for /\ and \/: 

let DoubletonSymmetry_THM = thm `;
  let x y be A;
  thus {x, y} = {y, x}
  proof
{x, y} = x  INSERT {y} /\ {y, x} = y INSERT {x} [defDoubleton];
! P. P IN {x, y} <=> P = x \/ P = y [defxy] by defDoubleton, IN_INSERT, 
IN_SING;
! P. P IN {y, x} <=> P = x \/ P = y by defDoubleton, IN_INSERT, 
IN_SING; 
  qed by -, defxy, EXTENSION`;;

But SET_RULE can do this!!!  And it can do what I wanted above: 

SET_RULE `{A, B, C} = {C, A, B} /\ {A, B, C} = {B, A, C}`;;
val it : thm = |- {A, B, C} = {C, A, B} /\ {A, B, C} = {B, A, C}

So thanks for telling me about a cool prover SET_RULE of yours.  If I could do 
this in miz3, I think my code would be prettier.  And maybe I don't need you to 
do anything, as this already works in miz3:
let DoubletonSymmetry_THM = thm `;
  let x y be A;
  thus {x, y} = {y, x}
  by SET_RULE`;;

let TripletonSymmetry_THM = thm `;
  let x y z be A;
  thus {x, y, z} = {y, x, z} /\ {x, y, z} = {y, z, x}
  by SET_RULE`;;

I have problems with your actual SET_RULE suggestion, or maybe I don't 
understand it: 

   If [the IN_ELIM_THM theorem seems complicated or unintuitive to
   explain to readers not versed in HOL], one could argue that
   provided you can prove semantic equivalence to something more
   intuitive, there's no reason to use a separate definition. For
   example, instead of your

 let union = new_definition
   `! s t:A->bool. s union t = \x. x IN s \/ x IN t`;;

   how about re-using the existing notion but simply setting up a
   different characterization 

 let union = SET_RULE `!s t:A->bool. s UNION t = \x. x IN s \/ x IN t`;;

Hmm... My long-range objective is to find work in the proof assistant world 
with my math skills, as among mathematician, I think I'm exceptionally 
interested in mathematical rigor.  But of course that will require me to really 
learn HOL Light (and maybe other proof assistants) very well, including 
IN_ELIM_THM.  But right now I'm trying to improve my position by getting a 
Geometry/HOL paper published in a math journal, and that I think requires me to 
explain HOL & miz3 is the simplest possible terms, kinda like Denzel Washington 
 in the movie Deja Vu telling the hotshot time-travel physicists, ``I know you 
have PhDs, so I'm going to try to make this really simple...''  

The only reason I'm using union is to spare my readers the  complicated and 
wonderful things that HOL folks have figured out, such as IN_ELIM_THM.  But 
SET_RULE (from sets.ml) uses IN_ELIM_THM!  The only problem I'm worrying about 
here is whether this short simple beautiful HOL Light isn't simple enough for 
my hotshot Math PhDs:

let Ray_DEF = new_definition
  `! A B. ray A B = {X | ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)}`;;

let IN_Ray = thm `;
 ! A B X. X IN ray A B <=> ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)
 by Ray_DEF, IN_ELIM_THM, REWRITE_TAC`;;

If we say my hotshots are supposed to learn HOL Light, then this code is 
perfectly fine, and I'm proud of myself for figuring it out.  This (which I'm 
also proud of figuring out) however is I think a lot simpler: 

let Rayz_DEF = new_definition
  `! A B X. rayz A B X  <=> ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)`;;

let IN_Rayz = thm `;
 ! A B X. X IN rayz A B <=> ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)
 by Rayz_DEF, IN, BETA_THM`;;

-- 
Best,
Bill 


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Here's something quite interesting that HOL Light taught me about geometry 
recently.  As I've said, I'm basically rigorously proving something that 
Hartshorne sketched in 
 Geometry, Euclid and Beyond, Undergraduate Texts in Math., Springer, 2000
that Hilbert's work gives a beautiful rigorization of Euclid's Elements.  
Hartshorne is a prominent mathematician, a Berkeley prof who wrote the standard 
beginning textbook on Algebraic Geometry, so we should take Hartshorne's Euclid 
book seriously.  But I've never thought its target audience of undergraduates 
not majoring in math would learn more than a broad-brush picture of Hilbert and 
Euclid, and I was very grateful to Hartshorne for this broad-brush picture, 
which I wasn't aware of earlier.  Anyway, it was clear to me that Hartshorne 
skipped a lot of steps in his proofs that folks can't fill in if they're not 
really serious about math, and I filled in many of these steps in my paper 
http://www.math.northwestern.edu/~richter/hilbert.pdf, which is now badly in 
need of revision because of all the steps HOL Light pointed out that I skipped 
and bungled!  But I had believed Hartshorne's claim that he discussed all of 
Euclid's book I results up to Prop I.28 that needed extra H!
 ilbert rigorization.  I don't believe that anymore, as I have quite long miz3 
proof of Prop I.24 (sort of a result about circle convexity), 70 lines not 
counting lemmas I just proved to help.  So score one for HOL Light.

Ramana, I had a dumb typo, and meant to write 

   You gave me some arguments against switching from set abstractions to 
abstractions

Freek, I just noticed that miz3 allows something you thought I would like, 
ending proofs with ;`;; instead of `;;, e.g. 
  qed by BGAncol, ANGLE, -, AngleTrichotomy_THM;
end;
  end;
`;;
This extra ; makes the syntax a bit simpler; we don't have to mention your 
optimization here.  Can you assure me this is a feature, not a bug, that I can 
count on putting in the extra semicolon?

Here's anothing set enumeration issue of mine.  One of the hardest aspects of 
my geometry coding sounds trivial.  I have a predicate 
Collinear A B C
but I often need the other 5 permutations of this statement, and have a result 
CollinearSymmetry_THM that allows permuting, which I use way more than I'd like 
to.  I don't enjoy writing code like this:
~Collinear B C O  /\ ~Collinear C O B   /\ ~Collinear C B O [BCOncol] 
by -, CollinearSymmetry_THM;
I just realized that in HOL, I can probably define instead 
Collinear {A, B, C}
and then I don't need to litter my code with CollinearSymmetry_THM.  HOL is so 
cool!

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks for responding, Ramana!  I see only one advantage to redefining set 
operations (e.g. INTER) as abstractions: it makes my code easier to read for me 
and my target audience of mathematicians, as I can substitute the very easy 
BETA_THM for the subtle and complicated IN_ELIM_THM that Michael and John just 
explained.  You gave me some arguments against switching from set abstractions 
to sets, and that's good.  However, 

Mathematicians distinguish between a subset of X and a boolean function on X, 
even though they're "the same thing", and I was worried that HOL wasn't making 
this distinction.  I think you're saying the set-abstraction/enumeration 
notation creates some sort of difference between  subsets and boolean 
functions, and I'm happy to hear that.  There's certainly something to be said 
for  abstraction barrier so we can change low-level representations, but I 
don't see the relevance of that here.  So that's great, and thanks for 
explaining. But I'm confused about the difference between set-abstractions and 
set-enumeration, both of which get printed as {...}.   Both INSERT and {} are 
defined as abstractions in HOL Light, and I assume the same is true for HOL4, 
and yet they they get printed with {...}:
#`x  INSERT {y}`;;
val it : term = `{x, y}`
#  `x  INSERT y INSERT {}`;;
val it : term = `{x, y}`
That surprises me.  I don't see why abstractions should get printed as {...}, 
and I don't see how INSERT and {} respect your barrier between abstractions and 
sets.  But {} is defined as (\ x:A. F), and this does not get printed as {...}:
#  `x  INSERT y INSERT (\ x. F)`;;
val it : term = `x INSERT y INSERT (\x. F)`

   This is the same reason to use the constant IN in your definitions
   and statements, even though many proofs go through easiest by
   rewriting it away first.

I think my motivation is different.  I have 1167 occurrences of the predicate 
IN in my miz3 Hilbert axiomatic geometry code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
 (now at 4180 lines, Euclid's book I formalized up to Proposition 26 (AAS)), 
and 369 occurrences of NOTIN.  I use IN and NOTIN to make it clear that I'm 
talking about sets, as in e.g. 
DropPerpendicularToLine_THM
  |- ∀ P l. Line l  ∧  P ∉ l
 ⇒ ∃ A D. A ∈ l ∧ D ∈ l ∧ Right (∡ P D A)
There's no way I'd be happy writing instead the equivalent 
 Line l  ∧  ¬(l P)
 ⇒ ∃ A D. l A ∧ l D ∧ Right (∡ P D A)
My mathematical audience wouldn't understand me, and I wouldn't understand my 
own code well enough to write it.  But I only have 3  occurrences of set 
abstractions {...} in my code, although I ought to add to that the  set 
abstractions {...} I use for INTER etc in sets.ml (5 by my count).  Now I'm 
certainly not willing to give up my set-enumerations, e.g. 
Segment_DEF |- ∀ A B. seg A B = {A, B} ∪ open (A,B)
or the operation INTER (which Emacs pre-processor turns ∪ into.I was very 
happy, a few months ago, when I realized that HOL had this set theory capacity! 
 But my readers won't spend much time, if any, looking at the set abstraction 
definition 
let UNION = new_definition
  `s UNION t = {x:A | x IN s \/ x IN t}`;;
in sets.ml, and my definition (which works just as well) 
let union = new_definition
  `! s t:A->bool. s union t = \ x. x IN s \/ x IN t`;;
isn't that much less readable, I'm thinking, if you only look at it once.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Ramana Kumar]

On Sat, Aug 18, 2012 at 5:55 AM, Bill Richter 
wrote:

> Right now I'm worrying about a different problem, that I've never
> understood sets.ml, especially its use of IN_ELIM_THM to prove the
> IN_ theorems.  After Michael taught me that a {...} is equal, in
> a complicated way, to a lambda, I thought, why not just define INTER,
> DELETE, UNION etc as lambdas?   Then the IN_ theorems are easy
> to prove, and I wrote up miz3 proofs myself that I could easily understand.
>

As I think was mentioned before, you don't have to (re)define the set
operations as abstractions (or "lambdas" as you call them), you can simply
prove that the existing definitions are equal to the desired abstractions
and then pretend those theorems are the definitions thereafter. (This has
the advantage of not introducing new constants, so you can use all the
existing theorems about the existing set operations without reproving them.)


> It would be easy to rewrite my 4000 lines of miz3 Hilbert code using
> lambda defs of INTER etc, and maybe that makes my code look simpler or more
> self-contained.  I'm still not convinced it's a good idea.  I think I'm
> missing a lot.  What is the point of the {...} definition of INTER, other
> than to see the nice {...} notation?  I love the {...} notation myself, but
> it's really equal to a lambda.  So  I wonder if the visual plus of some
> {...} in my code and in sets.ml offsets the fact that BETA_THM is so much
> simpler than IN_ELIM_THM.  I can't judge.  It was definitely a thrill for
> me to write readable understandable miz3 proofs of all the sets.mlresults 
> that I use.
>

Here's my attempt at rationalising this:

   - The point of using the set-abstraction/enumeration notation is that it
   makes it convenient to write set comprehensions (aka "set builder"
   notation) like { x + 6 | x < n }, which combine a filtering predicate with
   an element-building expression.
   - Using the same notation (and hence the same GSPEC constant or whatever
   it parses down to) for all set operations, including simple ones like { x |
   x IN s1 /\ x IN s2 }, gives a uniformity to the treatment of sets.
   - A uniform treatment of sets makes it easier (for you and for tactics)
   to see where the sets are (as opposed to other terms), and creates a
   (semi-transparent) abstraction barrier between sets and ordinary
   function-representing lambda abstractions (which is useful, for example, if
   one day you want to change the representation of sets). This is the same
   reason to use the constant IN in your definitions and statements, even
   though many proofs go through easiest by rewriting it away first. It's like
   giving variables meaningful names when the compiler doesn't care:
   distinguish the terms you want to treat as sets even though the logic
   doesn't care.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks for explaining GSPEC, SETSPEC & IN_ELIM_THM, Michael!  I'm glad to know 
that HOL4 can replicate my 1-line proof with SRW_TAC [][EXTENSION], similarly 
"complicated underneath the hood."   I'm confused by you paraphrasing Konrad as 
saying that your exercise was "annoying to prove."  It would seem to me now 
that Konrad probably meant that there's a slick 1-line proof that would be, for 
newbies like me, "hard to understand".

Thanks for also explaining IN_ELIM_THM, John!  Your 2nd fork is all I'm I'm 
worrying:

   the encoding of sets and the IN_ELIM_THM theorem that's used to
   unravel it seems complicated or unintuitive to explain to readers
   not versed in HOL?

And it's not just me who's not versed in HOL.  I'm hoping mathematicians and 
high school teachers are going to read my paper and code, so the less I 
befuddle them the better.  It doesn't follow that my lambda rewrite is a good 
idea, and I'd like your guidance here.  I didn't understand your SET_RULE 
rewrite, so I'll go read about SET_RULE.  Let me back up a bit:

Originally I had problems with set in miz3, but I think now that it was just my 
incompetence, and after I learned about IN_ELIM_THM, I could use {...} in my 
definitions of rays, angles etc.  I just posted a problem with miz3 and {...}, 
but that seems pretty minor to me.   So I'm no longer thinking that "compiler 
does a poor job on code." 

I still have set theory problems, but they don't seem to involve miz3.  Ramana 
and Michael helped me to eliminate new_axiom and new_type from the beginning of 
my simpler Tarski axiomatic geometry code.  But it got messy when I came to my 
defined infix predicate 
parse_as_infix("cong",(12, "right"));;
let cong_DEF = new_definition
 `a,b,c cong x,y,z <=>
   a,b === x,y /\ a,c === x,z /\ b,c === y,z`;;
and I never finished the rewrite.  I was amazed to get even that far.  

Right now I'm worrying about a different problem, that I've never understood 
sets.ml, especially its use of IN_ELIM_THM to prove the IN_ 
theorems.  After Michael taught me that a {...} is equal, in a complicated way, 
to a lambda, I thought, why not just define INTER, DELETE, UNION etc as 
lambdas?   Then the IN_ theorems are easy to prove, and I wrote up 
miz3 proofs myself that I could easily understand.  It would be easy to rewrite 
my 4000 lines of miz3 Hilbert code using lambda defs of INTER etc, and maybe 
that makes my code look simpler or more self-contained.  I'm still not 
convinced it's a good idea.  I think I'm missing a lot.  What is the point of 
the {...} definition of INTER, other than to see the nice {...} notation?  I 
love the {...} notation myself, but it's really equal to a lambda.  So  I 
wonder if the visual plus of some {...} in my code and in sets.ml offsets the 
fact that BETA_THM is so much simpler than IN_ELIM_THM.  I can't judge.  It !
 was definitely a thrill for me to write readable understandable miz3 proofs of 
all the sets.ml results that I use.

I can think of other miz3 problems that seem a lot more pressing that set 
notations, like being able to use 
#use ".ml";;
I'm guessing I'll have 5000 lines of code by the time I'm done, and what if 
somebody's machine can't store that much in the X-selection or whatever to 
paste it from one window to another?  And if we could #use miz3 code, couldn't 
it be included in distributions with straight HOL Light code?  

We had a vigorous discussion about about how powerful miz3 could be, or wants 
to be.   Here's what I learned, mostly from Michael.   Mizar, as opposed to 
miz3, seems to have intentionally weakened itself (i.e. you have to write out 
very complete proofs), and that's a plus for using Mizar in classrooms to 
police the students' homework.  I used to desire such weakness, but Michael 
convinced me that this is a bad idea (respect the students, don't shackle 
them!), and something that, at least in miz3, is just a matter of fiddling with 
the heuristics in a hit or miss way.  Freek explained there was no evidence for 
any shackling of miz3, which can indeed give 1-line proofs of my first 24 
theorems or so.   But it's odd that miz3 isn't even more powerful.  Freek 
pointed out that MESON has a built-in depth limit of 50 which GEN_MESON_TAC can 
remove.  But you seem to argue in the reference manual that raising the depth 
limit isn't a good idea:

   However, the inconvenience of doing this is seldom repaid by a
   dramatic improvement in performance, since exploration is normally
   at least exponential with the size bound.

Michael & I agreed we wanted miz3 to be more powerful, and you're the expert!  
Freek explained that all the calculation of "by" justifications is actually 
done in your code holby.ml.  Here's a dumb question.  I know MESON is an FOL 
prover that can't handle true HOL, and I think I have some true HOL code, owing 
to my sets.ml set theory.  But I have no idea how much my sets slow MESON down. 
 

-- 
Best,
Bill 

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 18/08/2012, at 4:18, Cris Perdue  wrote:

>REWRITE_CONV [IN_ELIM_THM] `{x + y | x IN P /\ 10 < y}`
> 
> it won't be disturbed because it doesn't have that external `x IN` at the 
> front.
> 
> It appears to me that Michael is trying to make a point here that I'm not 
> grasping, and that maybe his code snippet is not successful in demonstrating. 

I was trying to make the point that IN_ELIM_thm is a rewrite you can include as 
an argument to REWRITE without having your rewrite “destroying” normal set 
comprehension terms (which is what using [SETSPEC; GSPEC] would do).

The fact that REWRITE_CONV [IN_ELIM_thm] left your set comprehensions unchanged 
demonstrated this “safety property”.  Crafting rewrites so as to avoid what 
John nicely described as “collateral damage” is quite an art.

Michael--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Cris Perdue]

Michael's comments below have been quite interesting to me as part of
understanding set comprehensions better, so thanks Michael!  I have
comments and questions below:

On Thu, Aug 16, 2012 at 11:40 PM, Michael Norrish <
michael.norr...@nicta.com.au> wrote:

> On 17/08/12 07:51, Bill Richter wrote:
> > There's no reason for me to use these defs explicitly rather than
> IN_ELIM_THM, which uses them, but this definition bewilders me:
>
> > let IN_ELIM_THM = prove
> >   (`(!P x. x IN GSPEC (\v. P (SETSPEC v)) <=> P (\p t. p /\ (x = t))) /\
> > (!p x. x IN GSPEC (\v. ?y. SETSPEC v (p y) y) <=> p x) /\
> > (!P x. GSPEC (\v. P (SETSPEC v)) x <=> P (\p t. p /\ (x = t))) /\
> > (!p x. GSPEC (\v. ?y. SETSPEC v (p y) y) x <=> p x) /\
> > (!p x. x IN (\y. p y) <=> p x)`,
> >REPEAT STRIP_TAC THEN REWRITE_TAC[IN; GSPEC] THEN
> >TRY(AP_TERM_TAC THEN REWRITE_TAC[FUN_EQ_THM]) THEN
> >REWRITE_TAC[SETSPEC] THEN MESON_TAC[]);;
>
> > I'd rather use BETA_THM instead, and I can do this by using lambda defs
> of INTER, UNION etc instead of the {...} defs in sets.ml.
>
> The definitions of GSPEC and SETSPEC support the set-comprehension
> notation.
>
> When the HOL Light parser sees
>
>   { function on variables v1 v2.. vn |  predicate on variables v1 v2 ...
> vn }
>
> (e.g.,  { x + y | x ∈ P ∧ 10 < y })
>
> it converts this to
>
>GSPEC (λgv. ∃v1 v2 .. vn. SETSPEC gv (pred on v1 .. vn) (fn on v1 ..
> vn))
>
> where gv is a completely fresh variable.
>
> In the example, this would be
>
>GSPEC (λgv. ∃x y. SETSPEC gv (x ∈ P ∧ 10 < y) (x + y))
>
> This notation can be seen to have the right meaning if you expand the
> definitions of GSPEC and SETSPEC, and get
>
> GSPEC (λgv. ∃x y. (gv = x + y) ∧ x ∈ P ∧ 10 < y)
>   = (λgv. ∃x y. (gv = x + y) ∧ x ∈ P ∧ 10 < y)
>
> which is the λ-expression you'd write to get the meaning of that
> comprehension.
>   The first clause of IN_ELIM_THM is the rewrite you'd want to apply.
>
> Say you're trying to show that
>
>11 ∈ { x + y | x ∈ P ∧ 10 < y }
>
> then the first clause maps variable P to (λf. ∃x y. f (x ∈ P ∧ 10 < y) (x
> + y)),
> and then replaces the original term with
>
>(λf. ∃x y. f (x ∈ P ∧ 10 < y) (x + y)) (λp t. p ∧ 11 = t)
>
> which then β-reduces to
>
>∃x y. x ∈ P ∧ 10 < y ∧ 11 = x + y
>
> as desired.
>
> Using a rewrite like IN_ELIM is better than simply rewriting with SETSPEC
> and
> GSPEC's definition because doing that will destroy the structure of set
> comprehensions that you don't want to simplify just yet.
>
> E.g., try
>
>REWRITE_CONV [GSPEC, SETSPEC] `{x + y | x IN P /\ 10 < y}`


> and you'll get something pretty horrible out.  But, if you do


Well, maybe not so bad.  I did:

# REWRITE_CONV [GSPEC;SETSPEC] `{x + y | x IN P /\ 10 < y}`;;
val it : thm =
  |- {x + y | x IN P /\ 10 < y} =
 (\GEN%PVAR%219. ?x y. (x IN P /\ 10 < y) /\ GEN%PVAR%219 = x + y)

with a result that is a little simpler than what Michael suggested above,
except for the ugly printing of the generated variable.  Renaming gives a
right side of:

 \v. ?x y. (x IN P /\ 10 < y) /\ v = x + y


>
>REWRITE_CONV [IN_ELIM_THM] `{x + y | x IN P /\ 10 < y}`
>
> it won't be disturbed because it doesn't have that external `x IN` at the
> front.
>

It appears to me that Michael is trying to make a point here that I'm not
grasping, and that maybe his code snippet is not successful in
demonstrating. I have done:

# let tt = `{x + y | x IN P /\ 10 < y} = {x + y | x IN P /\ 10 < y}`;;
val tt : term = `{x + y | x IN P /\ 10 < y} = {x + y | x IN P /\ 10 < y}`

# let rhs = (rand (concl (REWRITE_CONV [IN_ELIM_THM] tt)));;
val rhs : term = `{x + y | x IN P /\ 10 < y}`

# aconv tt rhs;;
val it : bool = true

This says to me that the rewrite with IN_ELIM_THM did not do anything at
all, which is probably not the intended point. Michael, could you clarify
this for us?

Cheers,
Cris


>
> Michael
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[John Harrison]

Hi Bill,

| and I see no reason not to code up the parts of sets.ml using lambdas.  

Is the main motivation for doing this the fact that miz3's default
prover doesn't handle set notations very competently, or the fact that
the encoding of sets and the IN_ELIM_THM theorem that's used to
unravel it seems complicated or unintuitive to explain to readers not
versed in HOL?

If the former, then one might argue that I should just work on
improving the default automation, which would be useful in general
anyway. By analogy, if a compiler does a poor job on code, the
ideal is to fix the compiler instead of writing your own machine
code.

If the latter, one could argue that provided you can prove semantic
equivalence to something more intuitive, there's no reason to use a
separate definition. For example, instead of your

  let union = new_definition
`! s t:A->bool. s union t = \x. x IN s \/ x IN t`;;

how about re-using the existing notion but simply setting up a
different characterization 

  let union = SET_RULE `!s t:A->bool. s UNION t = \x. x IN s \/ x IN t`;;

As Michael explained, the underlying encodings of set abstractions are
a bit involved because they support quite general notations, and
IN_ELIM_THM is designed to remove the encoding without collateral
damage. Nevertheless what's going on is not too complicated in the
special case `{x | P x}`:

   {x | P x} 
 = GSPEC (\g. ?x. SETSPEC g (P x) x)
 = (\g. ?x. P x /\ g = x)
 = (\g. P g)
 = (\x. P x)

John.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 17/08/12 14:11, Bill Richter wrote:
> Michael, here's a 1-line HOL Light proof of your exercise
> { x | x ∈ P ∧ x ∈ Q} = λx. P x ∧ Q x:
>
> let IntersectionAbstractionIsLambda = prove (
 >   `!P Q :A->bool. {x | x IN P /\ x IN Q} = \x. x IN P /\ x IN Q`,
 > REWRITE_TAC[IN_ELIM_THM; EXTENSION]);;
>
> If you can't do that in HOL4, that's evidence for my feeling that IN_ELIM_THM
> is hard to understand.

The tactic in HOL4 would be

   SRW_TAC [][EXTENSION]

But it's complicated underneath the hood.  The mechanism is different to the 
way 
HOL Light does it, but it's still complex, and perhaps "hard to understand".

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 17/08/12 07:51, Bill Richter wrote:
> There's no reason for me to use these defs explicitly rather than 
> IN_ELIM_THM, which uses them, but this definition bewilders me:

> let IN_ELIM_THM = prove
>   (`(!P x. x IN GSPEC (\v. P (SETSPEC v)) <=> P (\p t. p /\ (x = t))) /\
> (!p x. x IN GSPEC (\v. ?y. SETSPEC v (p y) y) <=> p x) /\
> (!P x. GSPEC (\v. P (SETSPEC v)) x <=> P (\p t. p /\ (x = t))) /\
> (!p x. GSPEC (\v. ?y. SETSPEC v (p y) y) x <=> p x) /\
> (!p x. x IN (\y. p y) <=> p x)`,
>REPEAT STRIP_TAC THEN REWRITE_TAC[IN; GSPEC] THEN
>TRY(AP_TERM_TAC THEN REWRITE_TAC[FUN_EQ_THM]) THEN
>REWRITE_TAC[SETSPEC] THEN MESON_TAC[]);;

> I'd rather use BETA_THM instead, and I can do this by using lambda defs of 
> INTER, UNION etc instead of the {...} defs in sets.ml.

The definitions of GSPEC and SETSPEC support the set-comprehension notation.

When the HOL Light parser sees

  { function on variables v1 v2.. vn |  predicate on variables v1 v2 ... vn }

(e.g.,  { x + y | x ∈ P ∧ 10 < y })

it converts this to

   GSPEC (λgv. ∃v1 v2 .. vn. SETSPEC gv (pred on v1 .. vn) (fn on v1 .. vn))

where gv is a completely fresh variable.

In the example, this would be

   GSPEC (λgv. ∃x y. SETSPEC gv (x ∈ P ∧ 10 < y) (x + y))

This notation can be seen to have the right meaning if you expand the 
definitions of GSPEC and SETSPEC, and get

GSPEC (λgv. ∃x y. (gv = x + y) ∧ x ∈ P ∧ 10 < y)
  = (λgv. ∃x y. (gv = x + y) ∧ x ∈ P ∧ 10 < y)

which is the λ-expression you'd write to get the meaning of that comprehension. 
  The first clause of IN_ELIM_THM is the rewrite you'd want to apply.

Say you're trying to show that

   11 ∈ { x + y | x ∈ P ∧ 10 < y }

then the first clause maps variable P to (λf. ∃x y. f (x ∈ P ∧ 10 < y) (x + 
y)), 
and then replaces the original term with

   (λf. ∃x y. f (x ∈ P ∧ 10 < y) (x + y)) (λp t. p ∧ 11 = t)

which then β-reduces to

   ∃x y. x ∈ P ∧ 10 < y ∧ 11 = x + y

as desired.

Using a rewrite like IN_ELIM is better than simply rewriting with SETSPEC and 
GSPEC's definition because doing that will destroy the structure of set 
comprehensions that you don't want to simplify just yet.

E.g., try

   REWRITE_CONV [GSPEC, SETSPEC] `{x + y | x IN P /\ 10 < y}`

and you'll get something pretty horrible out.  But, if you do

   REWRITE_CONV [IN_ELIM_THM] `{x + y | x IN P /\ 10 < y}`

it won't be disturbed because it doesn't have that external `x IN` at the front.

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Michael, here's a 1-line HOL Light proof of your exercise { x | x ∈ P ∧ x ∈ Q} 
= λx. P x ∧ Q x:

let IntersectionAbstractionIsLambda = prove
 (`!P Q :A->bool. {x | x IN P /\ x IN Q} = \x. x IN P /\ x IN Q`,
  REWRITE_TAC[IN_ELIM_THM; EXTENSION]);;

If you can't do that in HOL4, that's evidence for my feeling that IN_ELIM_THM 
is hard to understand.  This clearly shows that John was right, that miz3 has 
some problems with sets, as I couldn't quite prove this in miz3.  The more 
general result has the same 1-line proof:

let AbstractionIsLambda = prove
 (`!P:A->bool. {x | P x} = \x. P x`,
  REWRITE_TAC[IN_ELIM_THM; EXTENSION]);;

So you really taught me something: a set abstraction {...} is a lambda!  That's 
really cool, and I see no reason not to code up the parts of sets.ml using 
lambdas.  I'll get much simpler proofs at the meaningless cost of not seeing a 
few nice {...} in the definitions.   I got started already, and redid my 4000 
lines of Hilbert axiomatic geometry miz3 code using lambda defs for INSERT, 
EMPTY, SING, and union.  
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
Each of these except UNION was already defined as a lambda in sets.ml, but I 
think my proofs of the basic properties are simpler.   At least, I can I 
understand them.Here's an example of my union defs & thms being used:

let Angle_DEF = new_definition
 ` angle A O B = ray O A union ray O B `;;

let AngleSymmetry_THM = thm `;
  ! A O B. angle A O B = angle B O A
  by Angle_DEF, union_COMM`;;
 
-- 
Best,
Bill 

let IN_INSERT = thm `;
  let x y be A;
  let s be A->bool;
  thus x IN (y INSERT  s) <=> (x = y) \/ x IN s
  by INSERT_DEF, IN, BETA_THM`;;

let NOT_IN_EMPTY = thm `;
  let x be A;
  thus ~(x IN {})
  by EMPTY, IN, BETA_THM`;;

let IN_SING = thm `;
  let x y be A;
  thus x IN {y}  <=>  x = y
  by NOT_IN_EMPTY, IN_INSERT, IN, BETA_THM`;;

let SING_SUBSET = thm `;
  let x be A;
  let s be A->bool;
  thus {x} SUBSET s <=> x IN s
  by IN_SING, SUBSET, IN, BETA_THM`;;

(* now define union as a lambda, not the set abstraction UNION from sets.ml *)

parse_as_infix("union",(16, "right"));;

let union = new_definition
  `! s t:A->bool. s union t = \x. x IN s \/ x IN t`;;

let union_SUBSET = thm `;
  let s t u be A->bool;
  thus (s union t) SUBSET u <=> s SUBSET u /\ t SUBSET u
  by union, SUBSET, IN, BETA_THM`;;

let IN_union = thm `;
  let x be A;
  let s t be A->bool;
  thus x IN (s union t) <=> x IN s \/ x IN t
  by union, IN, BETA_THM`;;

let union_COMM = thm `;
  let s t be A->bool;
  thus s union t = t union s

  proof
! x. x IN s union t  <=>  x IN s \/ x IN t [union1] by IN, union;
! x. x IN t union s  <=>  x IN s \/ x IN t by IN, union;
! x. x IN s union t  <=>  x IN t union s by union1, -;
  qed by -, EXTENSION`;;

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Michael, you're right, I don't want every lambda to be displayed as 
{...}.  But the main thing I learned from you is that there's no reason for me 
to not rewrite the parts of sets.ml that I use (IN_SING etc) to use lambda 
rather {...}, as the lambdas are actually equal to {...} defs. It looks nicer 
to have the curly braces, but that's just looks, and for my readers, it will be 
in just a few lines anyway.  I'll try to work this rewrite-sets.ml exercise.

 I came close enough to solving your {...} = lambda exercise, and I think it's 
a miz3 problem that I didn't completely solve it.  IN_INTER (which I used 
successfully) and IN_ELIM_THM (which was partly successful) both use the HOL 
Light functions GSPEC and SET_SPEC you suggested I use. I don't understand 
them, but their definitions are simple:
let GSPEC = new_definition
  `GSPEC (p:A->bool) = p`;;
let SETSPEC = new_definition
  `SETSPEC v P t <=> P /\ (v = t)`;;
There's no reason for me to use these defs explicitly rather than IN_ELIM_THM, 
which uses them, but this definition bewilders me:

let IN_ELIM_THM = prove
 (`(!P x. x IN GSPEC (\v. P (SETSPEC v)) <=> P (\p t. p /\ (x = t))) /\
   (!p x. x IN GSPEC (\v. ?y. SETSPEC v (p y) y) <=> p x) /\
   (!P x. GSPEC (\v. P (SETSPEC v)) x <=> P (\p t. p /\ (x = t))) /\
   (!p x. GSPEC (\v. ?y. SETSPEC v (p y) y) x <=> p x) /\
   (!p x. x IN (\y. p y) <=> p x)`,
  REPEAT STRIP_TAC THEN REWRITE_TAC[IN; GSPEC] THEN
  TRY(AP_TERM_TAC THEN REWRITE_TAC[FUN_EQ_THM]) THEN
  REWRITE_TAC[SETSPEC] THEN MESON_TAC[]);;

I'd rather use BETA_THM instead, and I can do this by using lambda defs of 
INTER, UNION etc instead of the {...} defs in sets.ml.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 16/08/2012, at 14:57, Bill Richter  wrote:

> So I didn't solve your exercise, which maybe would have required me to 
> understand your GSPEC and SET_SPEC, but I see the result should be true.  
> Still, I don't admit I was wrong, as your phrase "fancy way of writing" isn't 
> precise.  What I meant is that {x|..} is clearly not syntactic sugar for (λx. 
> ..).  I would be happy if it was, so that {x|..} = (λx. ..) would be true 
> without proof.  It didn't occur to me that they were equal by a complicated 
> proof. 

Indeed, you wouldn't want { x | ...} to be syntactic sugar for (\x. ...) 
because then otherwise innocuous lambda-expressions might get printed as set 
comprehensions.  

GSPEC and SET_SPEC are not "mine"; they're how HOL Light implements set 
comprehensions. I have no idea how they work.

> As you see, I actually write with your symbols ∪, ∈, ∩, ∀, ∃, and use an 
> Emacs preprocessor to turn these into the ordinary characters HOL Light uses. 
>  I'm glad to hear that HOL4, as well as Isabelle, uses these math symbols.  
> Which one of you did it first, I wonder?  It just hadn't occured to me to use 
> your λ, but I will starting now!  How hard would it be for HOL Light to be 
> able to do this?  Is that called supporting Unicode such tokens?

Isabelle supported “mathematical notation” a lot earlier than HOL4, but we do 
it in rather different ways.  I have no idea how HOL Light's 
parsing/pretty-printing machinery works in general.  I guess the thing to do 
would be to try overloading a Unicode symbol to an ASCII one and to see what 
happened...  HOL Light has some sort of overloading mechanism I believe, 
because I think it's possible to write x + y, for x of type :num or :real.

Michael
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Michael!  I definitely did not know that, but I should have, as it 
sounds like EXTENSION should prove it. Here's miz3 evidence for that, as this 
proof works with MESON solved at number 69,282:

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;; 
timeout := 30;;

let CurlyInterLambda_THM = thm `;
  let P Q be A->bool;
  thus P INTER Q = \x. x IN P /\ x IN Q

  proof
! y. y IN P INTER Q  <=>  y IN P /\ y IN Q [interdef] by IN_INTER;
! y. y IN \x. x IN P /\ x IN Q  <=>  y IN P /\ y IN Q by IN, BETA_THM;
  qed by -, interdef, IN, EXTENSION`;;


I don't think I should have needed IN in the qed line above, but it doesn't 
work without it.  For some reason, this didn't work, but I think it should have:

timeout := -1;;

let AbstractionInterLambda_THM = thm `;
  let P Q be A->bool;
  thus { x | x IN P /\ x IN Q} = \x. x IN P /\ x IN Q

  proof
! y. y IN { x | x IN P /\ x IN Q} <=>  y IN P /\ y IN Q [interdef] by 
REWRITE_TAC, IN_ELIM_THM;
! y. y IN \x. x IN P /\ x IN Q  <=>  y IN P /\ y IN Q by IN, BETA_THM;
! y. y IN { x | x IN P /\ x IN Q}  <=>  y IN \x. x IN P /\ x IN Q by -, 
interdef;
  qed by -, IN, EXTENSION`;;

Everything worked until the qed line, where I got a #1 inference error after a 
MESON number of 809,564, and 180,370 if I take out the IN which again seems 
unnecessary.  I was satisfied when miz3 bought my first line.  

So I didn't solve your exercise, which maybe would have required me to 
understand your GSPEC and SET_SPEC, but I see the result should be true.  
Still, I don't admit I was wrong, as your phrase "fancy way of writing" isn't 
precise.  What I meant is that {x|..} is clearly not syntactic sugar for (λx. 
..).  I would be happy if it was, so that {x|..} = (λx. ..) would be true 
without proof.  It didn't occur to me that they were equal by a complicated 
proof. 

   One exercise you might like to try is completely giving up on
   set-notation.  Write everything as predicates.  If you need notions
   like intersection, define predicate versions of these as well.
   Don't use IN, just use application of a predicate to the argument.

I don't think I'll work your exercise, as I think it would be a huge amount of 
work given my almost 4000 lines of code, and I don't see the point of it, as IN 
has such a simple definition in sets.ml:

let IN = new_definition
  `!P:A->bool. !x. x IN P <=> P x`;;

The exercise I'm considering is to continue using IN, but rewriting the parts 
of sets.ml that I use to use (λx. ..) definitions instead of {x|..}, just as 
you wrote:

   inter P Q = λx. P x ∧ Q x
   union P Q = λx. P x ∨ Q x

This would involve very little rewriting of my 4000 lines of miz3 code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
All it would cost me is my new {...} definitions e.g. 

let Ray_DEF = new_definition
  `∀ A B. ray A B = {X | ¬(A = B) ∧ Collinear A B X ∧ A ∉ open (X,B)}`;;

I'd just have to go back to my old definition 

let Ray_DEF = new_definition
  `∀ A B. ray A B X  ⇔  ¬(A = B) ∧ Collinear A B X ∧ A ∉ open (X,B)`;;

The advantage of my exercise would be that I'd understand my code a little 
better, as BETA_THM makes a lot more sense to me than IN_ELIM_THM!  My HOL 
ignorance is so vast that I don't even understand  REWRITE_TAC yet :)

BTW, here's an example of what Freek wrote, how it's mystifying to need the 
tactic REWRITE_TAC in miz3: 

let IN_Ray = thm `;
 ∀ A B X. X ∈ ray A B ⇔ ¬(A = B) ∧ Collinear A B X ∧ A ∉ open (X,B)
 by Ray_DEF, IN_ELIM_THM, REWRITE_TAC`;;

I get a #1 inference error if I take REWRITE_TAC out.  

As you see, I actually write with your symbols ∪, ∈, ∩, ∀, ∃, and use an Emacs 
preprocessor to turn these into the ordinary characters HOL Light uses.  I'm 
glad to hear that HOL4, as well as Isabelle, uses these math symbols.  Which 
one of you did it first, I wonder?  It just hadn't occured to me to use your λ, 
but I will starting now!  How hard would it be for HOL Light to be able to do 
this?  Is that called supporting Unicode such tokens?

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 15/08/12 14:41, Bill Richter wrote:
> A counterexample to what you wrote:

> If you never use that [{ n + 1 | n > 6 }] notation, then it's
> certainly fine to just view { x | P x } as a fancy way of writing
> (λx. P x).

> I'll give 3 reasons below to indicate this isn't true for me (I love
> your λ, BTW, and I suppose you can use it in HOL4). Let me first say
> that I think you understand this, as Konrad just posted something of
> this sort:

> each basic set operation (union, intersection, complement,
> powerset, difference, etc) is defined via a set abstraction. These
> definitions tend to be annoying to reason with, so for each
> definition, a theorem with the name IN_ is proved.

In essence, Konrad's point is that it's annoying to prove, for example:

  { x | x ∈ P ∧ x ∈ Q} = λx. P x ∧ Q x

Your examples (deleted) demonstrate that fact; you didn't manage to prove the 
equivalences.  Nonetheless they're true, and if you tried harder (perhaps 
feeding the definitions of GSPEC and SET_SPEC into your justifications), you 
might manage them.

My claim ("{x|..} is a fancy way of writing (λx. ..)") is true (by definition, 
even).  However, working with one notation may well turn out to be 
pragmatically 
easier.

One exercise you might like to try is completely giving up on set-notation. 
Write everything as predicates.  If you need notions like intersection, define 
predicate versions of these as well.  Don't use IN, just use application of a 
predicate to the argument.

E.g.,

   inter P Q = λx. P x ∧ Q x
   union P Q = λx. P x ∨ Q x
   image f P = λx. ∃y. P y ∧ x = f y

etc.

You may find the notation unsatisfying, but semantically you will be in exactly 
the same place.

Michael

PS: Yes, HOL4 supports Unicode tokens for things like ∪, ∈, ∩, ∀, ∃ and λ etc. 
Scroll to the bottom of 
http://hol.sourceforge.net/kananaskis-7-helpdocs/help/src-sml/htmlsigs/pred_setTheory.html
 
to see what this looks like for our pred_setTheory.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Michael, I'm really grateful to you, as you cleared up my main problem: 

   > Now is my interpretation of my own code correct?  

   Your interpretation of what you've written seems fine to me.

That's great.  I have to tell my audience of mathematicians what theorems HOL 
Light is verifying, even if I don't understand how.  I'd like to understand HOL 
better, and so let me ask some more baby questions.  I think my first def & thm 
let Interval_DEF = new_definition
  `! A B. open (A,B) = {X | Between A X B}`;;
let IN_Interval = prove
 (`! A B X. X IN open (A,B) <=> Between A X B`,
 REWRITE_TAC[IN_ELIM_THM; Interval_DEF]);;
give a counterexample to what you wrote:

   If you never use that [{ n + 1 | n > 6 }] notation, then it's
   certainly fine to just view { x | P x } as a fancy way of writing
   (λx. P x).

I'll give 3 reasons below to indicate this isn't true for me (I love your λ, 
BTW, and I suppose you can use it in HOL4).  Let me first say that I think you 
understand this, as Konrad just posted something of this sort:

   each basic set operation (union, intersection, complement,
   powerset, difference, etc) is defined via a set abstraction. These
   definitions tend to be annoying to reason with, so for each
   definition, a theorem with the name IN_ is proved. 

Konrad must be referring to the annoying-to-reason-with properties of {...}, 
because the sets.ml definition of INTER is very simple: 

let INTER = new_definition
  `s INTER t = {x:A | x IN s /\ x IN t}`;;

Reason-1) I'll write a lambda version of this, with miz3 code that proves the 
IN_ result:

#load "unix.cma";;
loadt "miz3/miz3.ml";;

parse_as_infix("inter",(20, "right"));;

let inter_DEF = new_definition
  `! s t:A->bool. s inter t = \x:A. x IN s /\ x IN t`;;

let IN_inter = thm `;
  let x be A;
  let s t be A->bool;
  thus x IN s inter t  <=>  x IN s /\ x IN t
  by inter_DEF, IN, BETA_THM`;;

This works fine, and my output is

# Warning: Benign redefinition
val inter_DEF : thm = |- !s t. s inter t = (\x. x IN s /\ x IN t)
#   val IN_inter : thm = |- !x s t. x IN s inter t <=> x IN s /\ x 
IN t

Reason-2) This miz3 code below seems to show that my {...} is not the obvious 
lambda:

let AbstractionLambda = thm `;
  let A B be point;
  thus A = A

  proof 
open (A,B) = {X | Between A X B} by Interval_DEF;
open (A,B) = \X:point. Between A X B by Interval_DEF;
open (A,B) = (\X. Between A X B) by Interval_DEF;
  qed`;;

Miz3 buys my first line (the definition), if I first run my Hilbert geometry 
code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
 but I get a #1 inference error after the 2nd and 3rd lines.  

Reason-3) Just to check, let's make sure that miz3 doesn't buy an 
IN_ proof similar to (1): 

let IM_interval = thm `;
  let A B X be point;
  thus X IN open (A,B) <=> Between A X B
  by Interval_DEF, IN, BETA_THM`;;

I get a #1 inference error.  So that's 3 reasons why I think my set 
abstractions {...} are not the obvious lambdas.  And it raises the obvious 
question: why don't I just rewrite sets.ml to use the obvious lambdas?  What 
will I miss, other than the beautiful {...} notation?  Even if what you wrote 
isn't technically true, it's true in spirit, right?  We really think that given 
a set X, we defined a subset of X by a boolean function on X, right?  


Rob, I looked up your Axiom of Replacement, which I wasn't familiar with:

   http://en.wikipedia.org/wiki/Axiom_schema_of_replacement
   In particular, ZF proves the consistency of Z, as the set Vω·2 is a model of 
Z constructible in ZF. [...] 
   The axiom schema of replacement is not necessary for the proofs of most 
theorems of ordinary mathematics. 

So I'm cool with HOL skipping the Axiom of Replacement, and I'll start saying 
ZC here instead ZFC.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Konrad!  Could you check to see if the HOL4 method of proving the IN_* 
theorems is simpler than the HOL Light method?  If it isn't, then maybe I 
should be satisfied with what I came up with,following sets.ml

let IN_Interval = prove
 (`! A B X. X IN open (A,B) <=> Between A X B`,
 REWRITE_TAC[IN_ELIM_THM; Interval_DEF]);;

Michael, I'm finding the Logic manual to be far more illuminating than the 
Stanford links in thewiki page on Type.  I see my problem: Russell & Whitehead 
foundationalized math using types, but Z&F also did it using sets, and 
mathematicians only learn about the ZFC way, and not the earlier type way.  I 
think I'm an expert on the Lambda calculus (paper on my web page), and I knew 
there is a typed LC, but I had no idea that Church worked on anything like set 
theory.  And yet he did, and I need to learn it!

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Rob Arthan]

On 14 Aug 2012, at 00:30, Cris Perdue wrote:

> 
> 
> On Mon, Aug 13, 2012 at 6:05 PM, Bill Richter  
> wrote:
> 
>I prefer not to say that a type is a set, because the set of all
>things having a type is expressible as \x. T (or {x | T}.



> 
>  Cris, I'm tempted to go with Michael, who sorta disagreed with you above.  
> Let me try to resolve the semi-disagreement.  My guess is that if you can 
> really write {x | T}, then that means that we're doing all our type theory in 
> a "universe" which in ZFC would actually be called a set.  The model of ZFC 
> isn't going to be a set, by Russell's paradox, and that's a way in which HOL 
> is weaker than ZFC, a weakness that doesn't bother me at all.\
> 
In HOL, if you just parse {x | T}, the bound variable x will be given the most 
general type, namely some type variable, so in a sense {x | T} does denote the 
set of a all things in the universe (since !x. x IN {x | T} is true). But it is 
probably easier to think of { x | T } as something with an implicit parameter 
(the type variable) that represents an unknown type, and can be specialised to 
any type of our choice. 

> Well, yes. I have frequently been omitting explicit type annotations on 
> variables (and constants). So if "i" is the notation for a type of 
> "individuals" then you can write {x:i | T} for the set of all individuals.

> And if "i->i" is the notation for functions from individuals to individuals 
> then {x:i->i | T} denotes the set of all functions from individuals to 
> individuals.  In the usual varieties of type theory the annotation for a type 
> must be finite in size, and this limits the universe of discourse.  As I 
> understand it this does result in a weaker system than ZFC.
> 
There are two aspects to that: an unsubtle one and a subtle one (that I only 
know of by hearsay and that I don't claim to understand).

The unsubtle aspect is that the axiom of replacement in ZFC makes it much much 
stronger than HOL by imposing a much bigger lower bound on the rank of the 
universe (which essentially means that you cannot define biggish ordinals or 
cardinals in a uniform way and can't define really big ordinals or cardinals at 
all). Really you should be comparing HOL with Zermelo set theory with choice 
(ZC). ZC and HOL feel very comparable - both have models with a universe of 
rank omega+omega. Using choice, you can construct cardinals like the 
cardinality of the continuum in an ad hoc way, but you can't fit it in nicely 
into an endless sequence of cardinals as you can in ZFC.

The subtle aspect, if my memory is correct, means that the untyped nature of ZC 
makes it stronger than HOL in rather subtle ways whose mathematical impact I am 
not qualified to assess (and is probably completely negligible for mainstream 
pure mathematics).  My recollection was that this follows from work of A.R.D. 
Mathias on Slim Models of Zermelo Set Theory (a paper on this can be downloaded 
from https://www.dpmms.cam.ac.uk/~ardm/). If anyone can give a better statement 
of the position on this, I would be grateful.

Regards,

Rob.




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 14/08/12 14:30, Cris Perdue wrote:

> I prefer not to say that a type is a set, because the set of all
> things having a type is expressible as \x. T (or {x | T}.

> Cris, I'm tempted to go with Michael, who sorta disagreed with
> you above. Let me try to resolve the semi-disagreement. My guess
> is that if you can really write {x | T}, then that means that
> we're doing all our type theory in a "universe" which in ZFC
> would actually be called a set. The model of ZFC isn't going to
> be a set, by Russell's paradox, and that's a way in which HOL is
> weaker than ZFC, a weakness that doesn't bother me at all.

> Well, yes. I have frequently been omitting explicit type annotations
> on variables (and constants). So if "i" is the notation for a type
> of "individuals" then you can write {x:i | T} for the set of all
> individuals. And if "i->i" is the notation for functions from
> individuals to individuals then {x:i->i | T} denotes the set of all
> functions from individuals to individuals. In the usual varieties of
> type theory the annotation for a type must be finite in size, and
> this limits the universe of discourse. As I understand it this does
> result in a weaker system than ZFC.

Indeed, you can't really write { x | T } in HOL, instead you have to write

   { x:sometype | T }

That "sometype" will correspond to a non-empty set S in the model, and your set 
comprehension is the predicate that is everywhere true over S.

In fact, the parser will allow you to write `{ x | T }`, but this is internally 
translated to `{x:A | T}`, where A is a polymorphic type variable.

As before, polymorphism slightly confuses the story.  The denotation of 
polymorphic A is not a single non-empty set, but rather a function from 
instantiations to sets.  This is described in the LOGIC manual.

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Cris Perdue]

On Mon, Aug 13, 2012 at 6:05 PM, Bill Richter  wrote:

> Michael, Konrad, Rob, Mark, Cris, thank you very much for all the
> messages!  This partly answers many questions that have puzzled me.  Among
> other things, I'm well on way to having to give you guys acknowledgments in
> my paper.  I think the point of an acknowledgment isn't to pay someone for
> help, but to tell the audience that this person is a valuable resource.
>  This was a valuable advice I got today.  I really had no idea what a type
> was, or the relationship between HOL and ZFC.  And John is back, with great
> looking photos that suggest he recharged his soul climbing mountains in the
> Rockies!   I'll mostly just ask a technical question about sets.ml raised
> by Michael & Konrad.
>
> Rob, your Andrews book looks good, and I grabbed the preface, and
> downloaded the wiki Type_theory entry.
>
> Michael, your comparison between the complicated { n + 1 | n > 6 } and the
> simpler { x | P x } suggests that sets.ml doesn't need such a complicated
> result as IN_ELIM_THM, that there should be a simpler proof of my first thm
> #   val IN_Interval : thm = |- !A B X. X IN open (A,B) <=>
> Between A X B
> that uses of course my first definition
> # val Interval_DEF : thm = |- !A B. open (A,B) = {X | Between A X B}
> but doesn't use IN_ELIM_THM.  Maybe even a miz3 proof!
>
> BTW the sets.ml defs of "HOL Light's GSPEC and SETSPEC" are very simple.
>  Here are the first 4 results of sets.ml:
> let IN = new_definition
>   `!P:A->bool. !x. x IN P <=> P x`;;
> let EXTENSION = prove
>  (`!s t. (s = t) <=> !x:A. x IN s <=> x IN t`,
>   REWRITE_TAC[IN; FUN_EQ_THM]);;
> let GSPEC = new_definition
>   `GSPEC (p:A->bool) = p`;;
> let SETSPEC = new_definition
>   `SETSPEC v P t <=> P /\ (v = t)`;;
>
> Michael, I need clarification here, because Rob said that HOL ought to be
> called "polymorphic typed set theory":
>
>A type is a non-empty set.  A term denotes a value in a type (i.e., an
> element
>of the non-empty set denoted by the type that term has).
>(Simplifying slightly; the above is true as long as the type is not
> polymorphic.)
>
> Konrad, this is very interesting, because it's so much like sets.ml:
>
>There is also a description of sets in HOL4 in the manual. Start at
>p. 102 of the HOL4 Description document:
>
> Yours & Michael's Description manual starts pretty much like sets.mlwhich I 
> cited above.   What I don't see is anything like what I'm having
> trouble with, the IN_* theorems.  Here are two from sets.ml I use
> constantly:
>
> let IN_INTER = prove
>  (`!s t (x:A). x IN (s INTER t) <=> x IN s /\ x IN t`,
>   REWRITE_TAC[IN_ELIM_THM; INTER]);;
>
> let IN_DELETE = prove
>  (`!s. !x:A. !y. x IN (s DELETE y) <=> x IN s /\ ~(x = y)`,
>   REWRITE_TAC[IN_ELIM_THM; DELETE]);;
>
> Is your HOL4 set abstraction mechanism so simple that you don't need a big
> hammer like IN_ELIM_THM?
>
>http://www.proof-technologies.com/misc/Glossary.txt
>
> Thanks, Mark, I'll read it!
>
>I prefer not to say that a type is a set, because the set of all
>things having a type is expressible as \x. T (or {x | T}.
>
>  Cris, I'm tempted to go with Michael, who sorta disagreed with you above.
>  Let me try to resolve the semi-disagreement.  My guess is that if you can
> really write {x | T}, then that means that we're doing all our type theory
> in a "universe" which in ZFC would actually be called a set.  The model of
> ZFC isn't going to be a set, by Russell's paradox, and that's a way in
> which HOL is weaker than ZFC, a weakness that doesn't bother me at all.
>

Well, yes. I have frequently been omitting explicit type annotations on
variables (and constants). So if "i" is the notation for a type of
"individuals" then you can write {x:i | T} for the set of all individuals.
 And if "i->i" is the notation for functions from individuals to
individuals then {x:i->i | T} denotes the set of all functions from
individuals to individuals.  In the usual varieties of type theory the
annotation for a type must be finite in size, and this limits the universe
of discourse.  As I understand it this does result in a weaker system than
ZFC.

-Cris

>
> --
> Best,
> Bill
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has chan

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Vincent Aravantinos]

Le 13 août 12 à 21:13, Bill Richter a écrit :


  http://plato.stanford.edu/entries/type-theory/ by Thierry Coquand
  (associated with Coq), and
  http://plato.stanford.edu/entries/type-theory-church/ by Peter  
Andrews


Cris, these look really good!  Are you telling me that the term Coq  
comes from Thierry Coquand's name?


"Coq" is both a reference to the "Calculus of Constructions" ("CoC")  
which is the type system underlying Coq, and a kind of tribute to  
Thierry Coquand who introduced this type system.



--
Vincent Aravantinos
PostDoctoral fellow, Concordia University, Hardware Verification Group
http://users.encs.concordia.ca/~vincent

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Konrad Slind]

> Konrad, this is very interesting, because it's so much like sets.ml:
>
>There is also a description of sets in HOL4 in the manual. Start at
>p. 102 of the HOL4 Description document:
>
> Yours & Michael's Description manual starts pretty much like sets.ml which I 
> cited above.

Not surprising. Those are the usual definitions of the standard
operations on sets. Also,
there is some overlap in naming styles between HOL4 and HOL Light. Many of the
theorems having to do with sets probably have the same name even,
because of the way these systems evolved from a common ancestor.

> What I don't see is anything like what I'm having trouble with, the IN_* 
> theorems.
> Here are two from sets.ml I use constantly:

Those theorems are indeed present and heavily used in HOL4. Think of
it this way:
each basic set operation (union, intersection, complement, powerset,
difference, etc)
is defined via a set abstraction. These definitions tend to be
annoying to reason with,
so for each definition, a theorem with the name IN_ is
proved. These theorems are rewrite rules that push the "IN" operator
deeper into whatever expression they are applied to. IN_INTER is a
typical example.

> Is your HOL4 set abstraction mechanism so simple that you don't need a
> big hammer like IN_ELIM_THM?

It's not simple, as a reading of section 3.5.1.1. in the HOL4
Description reveals.
When abstracting over multiple variables the representation becomes
unfortunately complex and hence expressions like

z IN {x + y | x * y > w}

do not easily reduce to something useful.

Konrad.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

   http://plato.stanford.edu/entries/type-theory/ by Thierry Coquand
   (associated with Coq), and
   http://plato.stanford.edu/entries/type-theory-church/ by Peter Andrews

Cris, these look really good!  Are you telling me that the term Coq comes from 
Thierry Coquand's name?  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Michael, Konrad, Rob, Mark, Cris, thank you very much for all the messages!  
This partly answers many questions that have puzzled me.  Among other things, 
I'm well on way to having to give you guys acknowledgments in my paper.  I 
think the point of an acknowledgment isn't to pay someone for help, but to tell 
the audience that this person is a valuable resource.  This was a valuable 
advice I got today.  I really had no idea what a type was, or the relationship 
between HOL and ZFC.  And John is back, with great looking photos that suggest 
he recharged his soul climbing mountains in the Rockies!   I'll mostly just ask 
a technical question about sets.ml raised by Michael & Konrad.  

Rob, your Andrews book looks good, and I grabbed the preface, and downloaded 
the wiki Type_theory entry.  

Michael, your comparison between the complicated { n + 1 | n > 6 } and the 
simpler { x | P x } suggests that sets.ml doesn't need such a complicated 
result as IN_ELIM_THM, that there should be a simpler proof of my first thm 
#   val IN_Interval : thm = |- !A B X. X IN open (A,B) <=> 
Between A X B
that uses of course my first definition 
# val Interval_DEF : thm = |- !A B. open (A,B) = {X | Between A X B}
but doesn't use IN_ELIM_THM.  Maybe even a miz3 proof!  

BTW the sets.ml defs of "HOL Light's GSPEC and SETSPEC" are very simple.  Here 
are the first 4 results of sets.ml:
let IN = new_definition
  `!P:A->bool. !x. x IN P <=> P x`;;
let EXTENSION = prove
 (`!s t. (s = t) <=> !x:A. x IN s <=> x IN t`,
  REWRITE_TAC[IN; FUN_EQ_THM]);;
let GSPEC = new_definition
  `GSPEC (p:A->bool) = p`;;
let SETSPEC = new_definition
  `SETSPEC v P t <=> P /\ (v = t)`;;

Michael, I need clarification here, because Rob said that HOL ought to be 
called "polymorphic typed set theory":

   A type is a non-empty set.  A term denotes a value in a type (i.e., an 
element 
   of the non-empty set denoted by the type that term has).
   (Simplifying slightly; the above is true as long as the type is not 
polymorphic.)

Konrad, this is very interesting, because it's so much like sets.ml:

   There is also a description of sets in HOL4 in the manual. Start at
   p. 102 of the HOL4 Description document:

Yours & Michael's Description manual starts pretty much like sets.ml which I 
cited above.   What I don't see is anything like what I'm having trouble with, 
the IN_* theorems.  Here are two from sets.ml I use constantly:

let IN_INTER = prove
 (`!s t (x:A). x IN (s INTER t) <=> x IN s /\ x IN t`,
  REWRITE_TAC[IN_ELIM_THM; INTER]);;

let IN_DELETE = prove
 (`!s. !x:A. !y. x IN (s DELETE y) <=> x IN s /\ ~(x = y)`,
  REWRITE_TAC[IN_ELIM_THM; DELETE]);;

Is your HOL4 set abstraction mechanism so simple that you don't need a big 
hammer like IN_ELIM_THM?  

   http://www.proof-technologies.com/misc/Glossary.txt

Thanks, Mark, I'll read it!

   I prefer not to say that a type is a set, because the set of all
   things having a type is expressible as \x. T (or {x | T}.

 Cris, I'm tempted to go with Michael, who sorta disagreed with you above.  Let 
me try to resolve the semi-disagreement.  My guess is that if you can really 
write {x | T}, then that means that we're doing all our type theory in a 
"universe" which in ZFC would actually be called a set.  The model of ZFC isn't 
going to be a set, by Russell's paradox, and that's a way in which HOL is 
weaker than ZFC, a weakness that doesn't bother me at all.  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Cris Perdue]

Bill,

On Sun, Aug 12, 2012 at 9:53 PM, Bill Richter  wrote:

> Thanks, Mark!  I looked at Tom Hales's Notices article, as you suggested
> www.ams.org/notices/200811/tx081101370p.pdf
> Now Tom is a great mathematician (he's the main reason I'm here), but Tom
> is now an HOL Light expert, and I think mathematicians can't be expected to
> understand him.  He starts out great:
>
>Much day-to-day mathematics is written at a level of abstraction
>that is indifferent to its exact representation as sets.
>
>This layer of abstraction is good news, because it allows us to
>shift from Zermelo-Fraenkel- Choice (ZFC) set theory to a different
>foundational system with equanimity and ease.
>
>HOL Light is a new axiomatic foundation with types, different from
>the usual ZFC.
>
> That sounds great, but here I want more details:
>
>The types are presented in the HOL Light System box.
>
>Terms are the basic mathematical objects of the HOL Light system. The
>syntax is based on Church’s lambda-calculus [to define functions]
>
> What is a type?  Compared to a set, I think. What is a term?
>
>1. Types: The collection of types is freely generated from type
>variables :A,:B,... and type constants :bool (boolean), :ind
>(infinite type), joined by arrows
>

Oooh. This item is talking about the syntax of the language. The concept of
"term" is also syntactic, the same thing as an expression in the
language. (These questions about types versus sets are wonderfully basic,
and it makes me happy to happy to see them asked by people other than me!)

Boolean-valued functions are sets. So \x. x < 3 is the set of integers less
than 3. As discussed, this is the same as {x | x < 3}. There are also sets
of sets. For example the set of all sets of integers containing exactly one
element is {S | size s = 1}.

In type theory, every value has a specific type as well as the ability to
be a member of various sets.  And every expression in the language has a
(syntactic!) type, and the type of every expression is fully determined by
the types of the variables in constants in it. For example if the constant
T has type bool and the constant  "==>" has type "function from bool and
bool to bool", then the expression "T ==> T" has type bool. For this
expression it is only necessary to see that it is an application of "==>"
to two arguments, but for lambdas there is slightly more syntactic
bookkeeping to be done. The language also has syntactic type checking, so
in this same example "T ==> T", the two input terms must have type bool or
the whole term is syntactically illegal.

It is customary to allow types of variables and constants to be omitted
when writing formulas in type theory where the types can be inferred by the
system. This is an important syntactic convenience.

Every syntactically correct expression in type theory can only produce
values that are of the type implied by the syntactic type of the
expression! And about the difference between types and sets, I prefer not
to say that a type is a set, because the set of all things having a type is
expressible as \x. T (or {x | T}. When explicit type annotation looks like
x:real or x:bool, then the set of all values of type bool is written as
{x:bool | T}.

It's helpful to look at Russell's paradox. It involves a set being or not
being a member of itself. In type theory syntax we would try to write "(X
X)". Fortunately in type theory this expression is syntactically illegal,
so Russell's paradox cannot be written.

Where in set theory the existence of a set must be proved, in type theory
many of these cases are no more than the syntactic type checking of the
expressions of your formulas. In type theory one could say that every value
expressible in a legal

Note also that in type theory there are things that are not sets! There are
integers, real numbers, booleans, functions from real numbers to real
numbers, sets of integers, and so on. This approach certainly fits basic
intuition.

Rob Arthan references Peter Andrews' textbook, which has been my entree
into type theory. That reminds me that online there are a couple of entries
in the Stanford Encyclopedia of Philosophy on type theory:

http://plato.stanford.edu/entries/type-theory/ by Thierry Coquand
(associated with Coq), and
http://plato.stanford.edu/entries/type-theory-church/ by Peter Andrews

Best regards,
Cris



>
> Isn't this supposed to be about sets?  My code (largely written by John)
> doesn't obviously obey Tom's rule:
> new_type("point",0);;
> new_type_abbrev("point_set",`:point->bool`);;
> new_constant("Between",`:point->point->point->bool`);;
> new_constant("Line",`:point_set->bool`);;
>
> Maybe I need to read something by Church.
>
>2. `{A,B}` is a set enumeration, not a set abstraction, so I'm not
>sure why you are pointing to the definition of "INSERT" (which is
>used in the representation of set enumerations) and then talking
>about set abstractions.
>
> Because it

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Konrad Slind]

>> Does HOL4 have anything comparable to sets.ml?

> Yes it will have, and it will probably be spread over many source code
> files, but I'm afraid I don't know where this is in the HOL4 source.  This
> is a question for HOL4 community, Michael et al.  I'm more of a HOL Light
> and HOL Zero person.

The counterpart to sets.ml in HOL4 is in

  /src/pred_set/src/pred_setScript.sml

There is also a description of sets in HOL4 in the manual. Start at p. 102
of the HOL4 Description document:

  
http://sourceforge.net/projects/hol/files/hol/kananaskis-7/kananaskis-7-description.pdf/download

Konrad.


On Mon, Aug 13, 2012 at 1:49 AM, "Mark"  wrote:
> Hi Bill,
>
>> Isn't this supposed to be about sets?
>
> No, HOL is about types.  Tom is informally explaining what the HOL logic is,
> rather than explaining it in terms of some other formal notation (e.g. ZFC
> set theory).
>
>> Can you explain how the set abstraction/enumerations of sets.ml are
> lambdas?
>
> It's like I said - a set abstraction is (of course) a set, and so is a set
> enumeration.  Sets in HOL Light and HOL4 are functions to boolean (i.e.
> "predicates").  A lambda is a function.  So therefore one can understand
> how, in HOL Light and HOL4, a set abstraction or enumeration might be a
> lambda.  Maybe I'm misunderstanding what your misunderstanding is...
>
> I think a problem for you here is that, in HOL Light, it's sometimes not
> easy to see through the syntactic sugar.  The parser will automatically
> parse a set enumeration as ` { 1, 2, 3 }`, whereas it is actually internally
> represented as `1 INSERT (2 INSERT (3 INSERT EMPTY))` (and parsing this
> longhand will give precisely the same internal term).  The pretty printer
> will always print out this internal representation as `{ 1, 2, 3 }`.  To get
> around this in HOL Light and see the true internal representation, I think
> you need to use the destructors 'dest_comb' and 'dest_abs'.  Then, if you
> want to know the definitions of the HOL constants used in the internal
> representation, you can examine the ML state variable 'the_definitions',
> which lists all constant definitions that have been made.
>
>> Does HOL4 have anything comparable to sets.ml?
>
> Yes it will have, and it will probably be spread over many source code
> files, but I'm afraid I don't know where this is in the HOL4 source.  This
> is a question for HOL4 community, Michael et al.  I'm more of a HOL Light
> and HOL Zero person.
>
> Mark.
>
>
> on 13/8/12 5:53 AM, Bill Richter  wrote:
>
>> Thanks, Mark!  I looked at Tom Hales's Notices article, as you suggested
>> www.ams.org/notices/200811/tx081101370p.pdf
>> Now Tom is a great mathematician (he's the main reason I'm here), but Tom
> is
>> now an HOL Light expert, and I think mathematicians can't be expected to
>> understand him.  He starts out great:
>>
>> Much day-to-day mathematics is written at a level of abstraction
>> that is indifferent to its exact representation as sets.
>>
>> This layer of abstraction is good news, because it allows us to
>> shift from Zermelo-Fraenkel- Choice (ZFC) set theory to a different
>> foundational system with equanimity and ease.
>>
>> HOL Light is a new axiomatic foundation with types, different from
>> the usual ZFC.
>>
>> That sounds great, but here I want more details:
>>
>> The types are presented in the HOL Light System box.
>>
>> Terms are the basic mathematical objects of the HOL Light system. The
>> syntax is based on Church’s lambda-calculus [to define functions]
>>
>> What is a type?  Compared to a set, I think. What is a term?
>>
>> 1. Types: The collection of types is freely generated from type
>> variables :A,:B,... and type constants :bool (boolean), :ind
>> (infinite type), joined by arrows
>>
>> Isn't this supposed to be about sets?  My code (largely written by John)
>> doesn't obviously obey Tom's rule:
>> new_type("point",0);;
>> new_type_abbrev("point_set",`:point->bool`);;
>> new_constant("Between",`:point->point->point->bool`);;
>> new_constant("Line",`:point_set->bool`);;
>>
>> Maybe I need to read something by Church.
>>
>> 2. `{A,B}` is a set enumeration, not a set abstraction, so I'm not
>> sure why you are pointing to the definition of "INSERT" (which is
>> used in the representation of set enumerations) and then talking
>> about set abstractions.
>>
>> Because it was about all that was explained about sets in the tutorial,
> and
>> because I was intrigued that INSERT was explicitly defined as a lambda in
>> sets.ml.
>>
>> But anyway, any set enumeration or set abstraction is of course a
>> set, and, in HOL Light, any set is a function (as explained by 1.),
>> which is what a lambda is, so there should be no surprise that a
>> set abstraction/enumeration can be expressed as a lambda in HOL
>> Light.
>>
>> Can you explain how the set abstraction/enumerations of sets.ml are
> lambdas?
>> Does HOL4 have anything comparable to sets.ml?
>>
>> Sorry, I had two typos in my last post.  I meant to say
>>
>> let I1 

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Rob Arthan]

On 13 Aug 2012, at 00:53, Bill Richter wrote:

> 
> What is a type?  
> 

If you have time to look at a textbook reference as background to all this, 
here is a good one describing a system that is very similar in spirit to HOL.

@BOOK{andrews,
author  = "Peter B. Andrews",
title   = "An Introduction to Mathematical Logic and Type
   Theory: To Truth Through Proof",
publisher   = AP,
year= 1986}

Regards,

Rob.




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Mark]

Hi Bill,

> Isn't this supposed to be about sets?

No, HOL is about types.  Tom is informally explaining what the HOL logic is,
rather than explaining it in terms of some other formal notation (e.g. ZFC
set theory).

> Can you explain how the set abstraction/enumerations of sets.ml are
lambdas?

It's like I said - a set abstraction is (of course) a set, and so is a set
enumeration.  Sets in HOL Light and HOL4 are functions to boolean (i.e.
"predicates").  A lambda is a function.  So therefore one can understand
how, in HOL Light and HOL4, a set abstraction or enumeration might be a
lambda.  Maybe I'm misunderstanding what your misunderstanding is...

I think a problem for you here is that, in HOL Light, it's sometimes not
easy to see through the syntactic sugar.  The parser will automatically
parse a set enumeration as ` { 1, 2, 3 }`, whereas it is actually internally
represented as `1 INSERT (2 INSERT (3 INSERT EMPTY))` (and parsing this
longhand will give precisely the same internal term).  The pretty printer
will always print out this internal representation as `{ 1, 2, 3 }`.  To get
around this in HOL Light and see the true internal representation, I think
you need to use the destructors 'dest_comb' and 'dest_abs'.  Then, if you
want to know the definitions of the HOL constants used in the internal
representation, you can examine the ML state variable 'the_definitions',
which lists all constant definitions that have been made.

> Does HOL4 have anything comparable to sets.ml?

Yes it will have, and it will probably be spread over many source code
files, but I'm afraid I don't know where this is in the HOL4 source.  This
is a question for HOL4 community, Michael et al.  I'm more of a HOL Light
and HOL Zero person.

Mark.


on 13/8/12 5:53 AM, Bill Richter  wrote:

> Thanks, Mark!  I looked at Tom Hales's Notices article, as you suggested
> www.ams.org/notices/200811/tx081101370p.pdf
> Now Tom is a great mathematician (he's the main reason I'm here), but Tom
is
> now an HOL Light expert, and I think mathematicians can't be expected to
> understand him.  He starts out great:
>
> Much day-to-day mathematics is written at a level of abstraction
> that is indifferent to its exact representation as sets.
>
> This layer of abstraction is good news, because it allows us to
> shift from Zermelo-Fraenkel- Choice (ZFC) set theory to a different
> foundational system with equanimity and ease.
>
> HOL Light is a new axiomatic foundation with types, different from
> the usual ZFC.
>
> That sounds great, but here I want more details:
>
> The types are presented in the HOL Light System box.
>
> Terms are the basic mathematical objects of the HOL Light system. The
> syntax is based on Church’s lambda-calculus [to define functions]
>
> What is a type?  Compared to a set, I think. What is a term?
>
> 1. Types: The collection of types is freely generated from type
> variables :A,:B,... and type constants :bool (boolean), :ind
> (infinite type), joined by arrows
>
> Isn't this supposed to be about sets?  My code (largely written by John)
> doesn't obviously obey Tom's rule:
> new_type("point",0);;
> new_type_abbrev("point_set",`:point->bool`);;
> new_constant("Between",`:point->point->point->bool`);;
> new_constant("Line",`:point_set->bool`);;
>
> Maybe I need to read something by Church.
>
> 2. `{A,B}` is a set enumeration, not a set abstraction, so I'm not
> sure why you are pointing to the definition of "INSERT" (which is
> used in the representation of set enumerations) and then talking
> about set abstractions.
>
> Because it was about all that was explained about sets in the tutorial,
and
> because I was intrigued that INSERT was explicitly defined as a lambda in
> sets.ml.
>
> But anyway, any set enumeration or set abstraction is of course a
> set, and, in HOL Light, any set is a function (as explained by 1.),
> which is what a lambda is, so there should be no surprise that a
> set abstraction/enumeration can be expressed as a lambda in HOL
> Light.
>
> Can you explain how the set abstraction/enumerations of sets.ml are
lambdas?
> Does HOL4 have anything comparable to sets.ml?
>
> Sorry, I had two typos in my last post.  I meant to say
>
> let I1 = new_axiom
> `! A B.  ~(A = B) ==> ?! l. Line l /\  A IN l /\ B IN l`;;
> says there is a unique "line" containing any two DISTINCT "points".
>
> if A, B refer to "points" a & b, then open (A,B) refers to the
> subset of point consisting of all "points" between a and b.
>
> --
> Best,
> Bill
>
>
>

> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Mark]

Hi Bill,

It's important to understand that the HOL4 Logic Manual gives a
(more-or-less) formal semantics of a formal logic.  That's two levels of
formal!  None of the set theory given in this document is actually part of
the HOL logic itself.  Rather the set theory is a formal way of portraying
to the reader what the HOL logic is.  This is a valuable document, making
crystal clear in minute detail exactly what the HOL logic is meant to be.
But it is not necessarily the best document to be reading for newcomers
wanting to get a good solid intuitive grasp.

By the way, I have a glossary of HOL terminology on my website which I think
will be of use to you, both in reading other documents about HOL, and as a
self-contained description of HOL (which can be read like an encyclopedia,
skipping between definitions).  It tries to explain clearly, concisely and
consistently all the concepts that you need to know.  Even though it is
written for HOL Zero, it applies to all HOL systems, and clearly states
where it is talking specifically about HOL Zero.  Unfortunately it is only a
text document at the moment, but one day I will make it HTML if anyone shows
any interest in it.  Get it here:

http://www.proof-technologies.com/misc/Glossary.txt

Mark.

on 13/8/12 5:18 AM, Bill Richter  wrote:

> Thanks, Michael!  I will treat the Logic Manual as a true description of
the
> HOL in HOL Light, and I will try harder to read it.  I have a lot of
trouble
> with your 3 sentences:
>
> Sets in HOL Light and HOL4 are predicates over their respective
> types.  Types correspond to non-empty sets (as already discussed).
> So, because any predicate bounded above corresponds to a ZFC set,
> the sets in HOL do also correspond to ZFC sets.
>
> One question would be: how does HOL Light turn my code into ZFC FOL?  That
> sounds like a tough question which I'm interested in, but it's not my real
> question.  I need to talk about sets to my audience of mathematicians in
my
> paper I'll submit soon to the Amer Math Monthly.  I have 3900 lines of
code
>
>
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGe
> ometry.tar.gz
> and I want to tell them something about which sets I'm using.  My first 4
> lines of code are
>
> new_type("point",0);;
> new_type_abbrev("point_set",`:point->bool`);;
> new_constant("Between",`:point->point->point->bool`);;
> new_constant("Line",`:point_set->bool`);;
>
> I think that says I told HOL Light to define a set called point and two
> functions
> Between: point x point x point ---> {True, False}
> Line: P(point) ---> {True, False}
> These sets & functions will be specified more closely by my axioms.  We
then
> (in our heads) define a "point" to be an element of point, and a "line" to
> be a subset of point (i.e. element of P(point)) which Line sends to True.
> I think my first axiom
> let I1 = new_axiom
> `! A B.  ~(A = B) ==> ?! l. Line l /\  A IN l /\ B IN l`;;
> says that given two elements of the set point, there is a unique line
> containing them.  I often write
> let A B C be point;
> I think that means that A, B and C are variables referring to "points",
and
> so (in our heads) we say that if
> Between A B C = True
> then the middle "point" is "between" the two outer "points".
> I have a definition
>
> let Interval_DEF = new_definition
> `! A B. open (A,B) = {X | Between A X B}`;;
>
> I think that says if A, B refer to two elements of a & a of the set point,
> then open (A,B) refers to the subset of point consisting of all "points"
> between a and a.
>
> Now is my interpretation of my own code correct?  I'm happy to cite the
> Logic Manual in my paper, but need to give audience more to go on.   Are
> there any examples in the Logic Manual that are as "concrete" as my
> description above?  I'm not too worried right now about how HOL Light is
> able to prove my statements about such sets are actually true.
>
> I have technical questions about sets defined by {...}, whether they're
> abstractions or enumerations (thanks for the new terminology, Mark).   My
> first theorem is
>
> let IN_Interval = prove
> (`! A B X. X IN open (A,B) <=> Between A X B`,
> REWRITE_TAC[IN_ELIM_THM; Interval_DEF]);;
>
> Here's the code in sets.ml for IN_ELIM_THM:
>
> let IN_ELIM_THM = prove
> (`(!P x. x IN GSPEC (\v. P (SETSPEC v)) <=> P (\p t. p /\ (x = t))) /\
> (!p x. x IN GSPEC (\v. ?y. SETSPEC v (p y) y) <=> p x) /\
> (!P x. GSPEC (\v. P (SETSPEC v)) x <=> P (\p t. p /\ (x = t))) /\
> (!p x. GSPEC (\v. ?y. SETSPEC v (p y) y) x <=> p x) /\
> (!p x. x IN (\y. p y) <=> p x)`,
> REPEAT STRIP_TAC THEN REWRITE_TAC[IN; GSPEC] THEN
> TRY(AP_TERM_TAC THEN REWRITE_TAC[FUN_EQ_THM]) THEN
> REWRITE_TAC[SETSPEC] THEN MESON_TAC[]);;
>
> Why do we have to work so hard to prove IN_Interval?  I would have thought
> that the {...} definition in  Interval_DEF just amounted to a lambda, so
> open (A,B) = {X | Between A X B}
> means that
> open (A,B) = \X. Between A X B
> With that lambda definition of open (A,B), my the

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 13/08/12 14:53, Bill Richter wrote:
> That sounds great, but here I want more details:
>
> The types are presented in the HOL Light System box.
>
> Terms are the basic mathematical objects of the HOL Light system. The
> syntax is based on Church’s lambda-calculus [to define functions]
>
> What is a type?  Compared to a set, I think. What is a term?

A type is a non-empty set.  A term denotes a value in a type (i.e., an element 
of the non-empty set denoted by the type that term has).

(Simplifying slightly; the above is true as long as the type is not 
polymorphic.)

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 13/08/12 14:17, Bill Richter wrote:
> Thanks, Michael!  I will treat the Logic Manual as a true description of the
> HOL in HOL Light, and I will try harder to read it.  I have a lot of trouble
> with your 3 sentences:

>>Sets in HOL Light and HOL4 are predicates over their respective types.  
>> Types
>>correspond to non-empty sets (as already discussed). So, because any
>>predicate bounded above corresponds to a ZFC set, the sets in HOL do also
>>correspond to ZFC sets.

> One question would be: how does HOL Light turn my code into ZFC FOL?  That
> sounds like a tough question which I'm interested in, but it's not my real
> question.

The easy answer is that HOL Light does not turn your code into ZFC FOL at all. 
Not even a little bit.  When you carry out a HOL proof, you use the proof 
system 
that is described in the Logic manual.  That proof system doesn't even have to 
treat implication and universal quantification as primitive.  In particular, in 
HOL Light, implication, and existential and universal quantification are 
derived 
notions.  That means you can be sure that at the very bottom level, the proof 
system is not doing the traditional FOL thing (involving modus ponens, 
generalisation etc).  Those proof principles are present in HOL, but as derived 
notions.

As for my quoted paragraph, I hope it is just the 3rd sentence that is causing 
you trouble.  If you write a predicate on a HOL type (say (λn:num. n > 6)), 
then 
this is equal to the HOL "set" { n | n > 6 }.  Now, in contrast, when you get 
really fussy with FOL set theory, you're not allowed to write { n | n > 6 }; 
you 
have to use the axiom of separation, and impose an upper bound.  For my 
example, 
I might take the reals, or the integers or the natural numbers as my "bound".  
I 
don't need to do that in HOL because the type over which the predicate is 
expressed is itself the bound.

> new_type("point",0);; new_type_abbrev("point_set",`:point->bool`);;
> new_constant("Between",`:point->point->point->bool`);;
> new_constant("Line",`:point_set->bool`);;
>
> I think that says ...

> Now is my interpretation of my own code correct?  I'm happy to cite the Logic
> Manual in my paper, but need to give audience more to go on.   Are there any
> examples in the Logic Manual that are as "concrete" as my description above?

Your interpretation of what you've written seems fine to me.

> I have technical questions about sets defined by {...}, whether they're
> abstractions or enumerations (thanks for the new terminology, Mark).

They can be either.  The test is whether or not there's a set comprehension | 
(bar) in there or not.  If you write { x | P x }, you're defining an 
abstraction.  If you write { x; y; z }, that's an enumeration.

> Are you & Mark saying that HOL Light has a more complicated definition of {X
> | Between A X B}, one that requires the serious technicality of IN_ELIM_THM?
> Can I just rewrite sets.ml myself with ordinary lambdas so that I don't need
> IN_ELIM_THM?  I think my audience of mathematicians needs some explanation,
> and hoping you'll give me one.

I'm not sure quite how HOL Light's GSPEC and SETSPEC constants work (they're 
different from HOL4's treatment of this syntax), but I imagine the 
complications 
are there only to allow for notations like

   { n + 1 | n > 6 }

where what appears to the left of the bar may be an arbitrary term.  (This 
notation is really just a nice way of writing an image construction of course.)

If you never use that notation, then it's certainly fine to just view

   { x | P x }

as a fancy way of writing (λx. P x).  If you want to investigate, try the 
following:

   let t = `{ x | x > 4 }`;;
   let (f,ab) = dest_comb t;; (* f will be the GSPEC constant *)
   let (bv,bod) = dest_abs ab;;
   (* etc; use dest_comb, dest_abs as necessary *)

Also try the same with more complicated comprehensions.

In this way, you can see past the pretty-printing and get at what is really 
going on with that notation.

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Mark!  I looked at Tom Hales's Notices article, as you suggested 
www.ams.org/notices/200811/tx081101370p.pdf
Now Tom is a great mathematician (he's the main reason I'm here), but Tom is 
now an HOL Light expert, and I think mathematicians can't be expected to 
understand him.  He starts out great: 

   Much day-to-day mathematics is written at a level of abstraction
   that is indifferent to its exact representation as sets.

   This layer of abstraction is good news, because it allows us to
   shift from Zermelo-Fraenkel- Choice (ZFC) set theory to a different
   foundational system with equanimity and ease.

   HOL Light is a new axiomatic foundation with types, different from
   the usual ZFC.

That sounds great, but here I want more details:

   The types are presented in the HOL Light System box.

   Terms are the basic mathematical objects of the HOL Light system. The
   syntax is based on Church’s lambda-calculus [to define functions] 

What is a type?  Compared to a set, I think. What is a term?  

   1. Types: The collection of types is freely generated from type
   variables :A,:B,... and type constants :bool (boolean), :ind
   (infinite type), joined by arrows

Isn't this supposed to be about sets?  My code (largely written by John) 
doesn't obviously obey Tom's rule:
new_type("point",0);;
new_type_abbrev("point_set",`:point->bool`);;
new_constant("Between",`:point->point->point->bool`);;
new_constant("Line",`:point_set->bool`);;

Maybe I need to read something by Church.  

   2. `{A,B}` is a set enumeration, not a set abstraction, so I'm not
   sure why you are pointing to the definition of "INSERT" (which is
   used in the representation of set enumerations) and then talking
   about set abstractions.  

Because it was about all that was explained about sets in the tutorial, and 
because I was intrigued that INSERT was explicitly defined as a lambda in 
sets.ml.

   But anyway, any set enumeration or set abstraction is of course a
   set, and, in HOL Light, any set is a function (as explained by 1.),
   which is what a lambda is, so there should be no surprise that a
   set abstraction/enumeration can be expressed as a lambda in HOL
   Light.

Can you explain how the set abstraction/enumerations of sets.ml are lambdas?  
Does HOL4 have anything comparable to sets.ml?  

Sorry, I had two typos in my last post.  I meant to say 

   let I1 = new_axiom
 `! A B.  ~(A = B) ==> ?! l. Line l /\  A IN l /\ B IN l`;;
   says there is a unique "line" containing any two DISTINCT "points".  

if A, B refer to "points" a & b, then open (A,B) refers to the
   subset of point consisting of all "points" between a and b.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Michael!  I will treat the Logic Manual as a true description of the 
HOL in HOL Light, and I will try harder to read it.  I have a lot of trouble 
with your 3 sentences: 

   Sets in HOL Light and HOL4 are predicates over their respective
   types.  Types correspond to non-empty sets (as already discussed).
   So, because any predicate bounded above corresponds to a ZFC set,
   the sets in HOL do also correspond to ZFC sets.

One question would be: how does HOL Light turn my code into ZFC FOL?  That 
sounds like a tough question which I'm interested in, but it's not my real 
question.  I need to talk about sets to my audience of mathematicians in my 
paper I'll submit soon to the Amer Math Monthly.  I have 3900 lines of code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
and I want to tell them something about which sets I'm using.  My first 4 lines 
of code are

new_type("point",0);;
new_type_abbrev("point_set",`:point->bool`);;
new_constant("Between",`:point->point->point->bool`);;
new_constant("Line",`:point_set->bool`);;

I think that says I told HOL Light to define a set called point and two 
functions
Between: point x point x point ---> {True, False}
Line: P(point) ---> {True, False}
These sets & functions will be specified more closely by my axioms.  We then 
(in our heads) define a "point" to be an element of point, and a "line" to be a 
subset of point (i.e. element of P(point)) which Line sends to True.   I think 
my first axiom 
let I1 = new_axiom
  `! A B.  ~(A = B) ==> ?! l. Line l /\  A IN l /\ B IN l`;;
says that given two elements of the set point, there is a unique line 
containing them.  I often write 
  let A B C be point;
I think that means that A, B and C are variables referring to "points", and so 
(in our heads) we say that if 
Between A B C = True
then the middle "point" is "between" the two outer "points". 
I have a definition 

let Interval_DEF = new_definition
  `! A B. open (A,B) = {X | Between A X B}`;;

I think that says if A, B refer to two elements of a & a of the set point, then 
open (A,B) refers to the subset of point consisting of all "points" between a 
and a.  

Now is my interpretation of my own code correct?  I'm happy to cite the Logic 
Manual in my paper, but need to give audience more to go on.   Are there any 
examples in the Logic Manual that are as "concrete" as my description above?  
I'm not too worried right now about how HOL Light is able to prove my 
statements about such sets are actually true. 

I have technical questions about sets defined by {...}, whether they're 
abstractions or enumerations (thanks for the new terminology, Mark).   My first 
theorem is 

let IN_Interval = prove
 (`! A B X. X IN open (A,B) <=> Between A X B`,
 REWRITE_TAC[IN_ELIM_THM; Interval_DEF]);;

Here's the code in sets.ml for IN_ELIM_THM:

let IN_ELIM_THM = prove
 (`(!P x. x IN GSPEC (\v. P (SETSPEC v)) <=> P (\p t. p /\ (x = t))) /\
   (!p x. x IN GSPEC (\v. ?y. SETSPEC v (p y) y) <=> p x) /\
   (!P x. GSPEC (\v. P (SETSPEC v)) x <=> P (\p t. p /\ (x = t))) /\
   (!p x. GSPEC (\v. ?y. SETSPEC v (p y) y) x <=> p x) /\
   (!p x. x IN (\y. p y) <=> p x)`,
  REPEAT STRIP_TAC THEN REWRITE_TAC[IN; GSPEC] THEN
  TRY(AP_TERM_TAC THEN REWRITE_TAC[FUN_EQ_THM]) THEN
  REWRITE_TAC[SETSPEC] THEN MESON_TAC[]);;

Why do we have to work so hard to prove IN_Interval?  I would have thought that 
the {...} definition in  Interval_DEF just amounted to a lambda, so 
open (A,B) = {X | Between A X B}
means that 
open (A,B) = \X. Between A X B
With that lambda definition of open (A,B), my theorem IN_Interval looks really 
obvious, it just needs the first definition of sets.ml 

let IN = new_definition
  `!P:A->bool. !x. x IN P <=> P x`;;

Are you & Mark saying that HOL Light has a more complicated definition of {X | 
Between A X B}, one that requires the serious technicality of IN_ELIM_THM?  Can 
I just rewrite sets.ml myself with ordinary lambdas so that I don't need 
IN_ELIM_THM?  I think my audience of mathematicians needs some explanation, and 
hoping you'll give me one. 

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Mark]

Hi Bill,

> ... My main problem is that I don't understand HOL, so I don't know what
> theorems HOL Light is proving for me.   The HOL4 Logic manual looks like
> a very respectable CS document, but I haven't been able to read it yet,
and
> it's not a HOL Light document.

And it's not a particularly light HOL document either!  I agree we are
missing a neat self-contained informal explanation of the HOL language and
logic.  I'm trying to think of a good paper to point you to.  Maybe Tom
Hale's AMS paper from 2008.  Alternatively, chapters 3 & 4 of my incomplete
HOL Zero manual (bundled with the HOL Zero system) explain everything, but
then this is for HOL Zero and not for HOL Light, although it may still be
helpful for your purposes.

> With my Tarski code, I would be happy to
> say (though I don't quite understand it) that HOL Light was verifying my
FOL
> proofs using Tarski's geometry axioms.  But there's real  HOL in my
Hilbert
> code funneled through sets.ml.  Of course I know what results I meant to
> prove, and my results use sets as mathematicians customarily use sets.  I
> figure that's the result that HOL Light proved for me, but I'm missing the
> translation.

I'm not sure exactly what you mean when you say "translation".
Specifically, a translation from what to what?  The "from" or the "to" could
conceivably be:
HOL Light term quotation syntax
HOL Light primitive term syntax
HOL Light miz3 proof scripts
HOL Light inference rules
conventional mathematical notation
some formal mathematical logic that is not HOL

Mark.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Mark]

Hi Bill,

There are a few points which you may or may not already realise.  Sorry if
these are obvious, but I haven't been following the (very lengthy!) thread
in detail.

1. Just checking you understand this:  In HOL Light and HOL4 (but not
ProofPower HOL), sets are represented as functions to booleans, so a set
with elements of type A is represented as a function from A to bool.  Enter
the following in a HOL Light session to confirm this:
 type_of ` { 10 }`;;

> The tutorial then explains {A, B} is syntactic sugar for A INSERT B INSERT
> {}. INSERT is defined in sets.ml as
>
> let INSERT_DEF = new_definition
> `x INSERT s = \y:A. y IN s \/ (y = x)`;;
>
> That kinda sounds like saying a set abstraction is a lambda ...

2. `{A,B}` is a set enumeration, not a set abstraction, so I'm not sure why
you are pointing to the definition of "INSERT" (which is used in the
representation of set enumerations) and then talking about set abstractions.
 But anyway, any set enumeration or set abstraction is of course a set, and,
in HOL Light, any set is a function (as explained by 1.), which is what a
lambda is, so there should be no surprise that a set abstraction/enumeration
can be expressed as a lambda in HOL Light.

> ... kinda sounds like saying a set abstraction is a lambda, but that
> can't be, because p 100 of the HOL Light tutorial says something I
> need to understand:
>
> Since MESON’s handling of lambdas is a bit better than its handling
> of set abstractions,

3. Lambdas are used in the representation of set abstractions, but the
representation is quite complicated and also involves a few other things,
and presumably it is these other things that MESON is not so good at.

Hope this helps.

Mark.

on 12/8/12 3:45 AM, Bill Richter  wrote:

> I made real progress on my set theory problem, but I'd like to do even
> better.  My 3860 lines of miz3 Hilbert axiomatic geometry code
>
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGe
> ometry.tar.gz now uses set abstraction to define rays:
>
> let Ray_DEF = new_definition
> `! A B. ray A B = {X:point | ~(A = B) /\ Collinear A B X /\ A NOTIN open
> (X,B)}`;;
>
> This works because of the theorem I then prove, following sets.ml
>
> let IN_Ray = prove
> (`! A B X:point. X IN ray A B <=> ~(A = B) /\ Collinear A B X /\ A NOTIN
> open (X,B)`,
> REWRITE_TAC[IN_ELIM_THM; Ray_DEF]);;
>
> I then replaced every occurrence of `IN, Ray_DEF' with the
sets.ml-friendly
> `IN_Ray'.  I have no idea why IN_Ray works, and I borrowed code from
> sets.ml:
>
> let UNION = new_definition
> `s UNION t = {x:A | x IN s \/ x IN t}`;;
>
> let IN_UNION = prove
> (`!s t (x:A). x IN (s UNION t) <=> x IN s \/ x IN t`,
> REWRITE_TAC[IN_ELIM_THM; UNION]);;
>
> This is partly explained on p 91--92 of the HOL Light tutorial:
>
> In order to eliminate the set abstraction from a term of the form
> x ∈ {t | p}, rewrite with the theorem IN_ELIM_THM [of sets.ml], which
> will
> nicely eliminate the internal representation of set abstractions, e.g.
>
> # REWRITE_CONV[IN_ELIM_THM]
> ‘z IN {3 * x + 5 * y | x IN (:num) /\ y IN (:num)}‘;;
> val it : thm =
> |- z IN {3 * x + 5 * y | x IN (:num) /\ y IN (:num)} <=>
> (?x y. (x IN (:num) /\ y IN (:num)) /\ z = 3 * x + 5 * y)
>
> The tutorial then explains {A, B} is syntactic sugar for A INSERT B INSERT
> {}. INSERT is defined in sets.ml as
>
> let INSERT_DEF = new_definition
> `x INSERT s = \y:A. y IN s \/ (y = x)`;;
>
> That kinda sounds like saying a set abstraction is a lambda, but that
can't
> be, because p 100 of the HOL Light tutorial says something I need to
> understand:
>
> Since MESON’s handling of lambdas is a bit better than its handling
> of set abstractions,
>
> If anyone can explain any of these mysteries, I'd be happy to listen.  But
> what I'd really like is a way to prove IN_Ray in miz3.
>
> --
> Best,
> Bill
>
>
>

> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
>
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 11/08/2012, at 17:05, Bill Richter  wrote:

> My main problem is that I don't understand HOL, so I don't know what theorems 
> HOL Light is proving for me.   The HOL4 Logic manual looks like a very 
> respectable CS document, but I haven't been able to read it yet, and it's not 
> a HOL Light document.   

HOL Light and HOL4 implement the same logic by design.  For this reason, the 
Logic Manual is the best reference describing the HOL Light logic's semantics. 

> With my Tarski code, I would be happy to say (though I don't quite understand 
> it) that HOL Light was verifying my FOL proofs using Tarski's geometry 
> axioms.  But there's real  HOL in my Hilbert code funneled through sets.ml.  
> Of course I know what results I meant to prove, and my results use sets as 
> mathematicians customarily use sets.  I figure that's the result that HOL 
> Light proved for me, but I'm missing the translation.  

Sets in HOL Light and HOL4 are predicates over their respective types.  Types 
correspond to non-empty sets (as already discussed).  So, because any predicate 
bounded above corresponds to a ZFC set, the sets in HOL do also correspond to 
ZFC sets.

Michael
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

My old definition of ray OK.  The problem was int_angle, where I needed this 
clumsy looking usage, with the useless and "unsettling" first line of the proof


let InteriorWellDefined_THM = thm `;
  let A O B X P be point;
  assume P IN int_angle A O B [H1];
  assume X IN ray O B DELETE O [H2];
  thus P IN int_angle A O X

  proof
int_angle A O B P by H1, IN;
consider a b such that
~Collinear A O B /\ 
Line a /\ O IN a /\ A IN a /\ P NOTIN a /\ 
Line b /\ O IN b /\ B IN b /\ P NOTIN b /\ 
P,B same_side a /\ P,A same_side b [def_int] by -, InteriorAngle_DEF;
[...]

With my new code, it looks much better:

let InteriorWellDefined_THM = thm `;
  let A O B X P be point;
  assume P IN int_angle A O B [H1];
  assume X IN ray O B DELETE O [H2];
  thus P IN int_angle A O X

  proof
consider a b such that
~Collinear A O B /\ 
Line a /\ O IN a /\ A IN a /\ P NOTIN a /\ 
Line b /\ O IN b /\ B IN b /\ P NOTIN b /\ 
P,B same_side a /\ P,A same_side b [def_int] by -, IN_InteriorAngle;
[...]

The fixed comes from the set abstraction definition and sets.ml-type theorem 

let InteriorAngle_DEF = new_definition
 `∀ A O B P. 
  int_angle A O B = {P:point | ¬Collinear A O B ∧ ∃ a b. 
  Line a ∧ O ∈ a ∧ A ∈ a ∧ Line b ∧ O ∈ b ∧ B ∈ b ∧
  P ∉ a ∧ P ∉ b ∧ P,B same_side a ∧ P,A same_side b}`;;

let IN_InteriorAngle = prove
 (`∀ A O B P:point. P ∈ int_angle A O B ⇔ 
 ¬Collinear A O B ∧ ∃ a b. 
 Line a ∧ O ∈ a ∧ A ∈ a ∧ Line b ∧ O ∈ b ∧ B ∈ b ∧
 P ∉ a ∧ P ∉ b ∧ P,B same_side a ∧ P,A same_side b`,
  REWRITE_TAC[IN_ELIM_THM; InteriorAngle_DEF]);;

I think it's fine for me to write `IN_ELIM_THM' HOL Light code in my miz3 code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
that I don't understand, because `IN_ELIM_THM' code of this sort fills sets.ml, 
which I'm making heavy use of.  It would be nice to understand my own code, but 
that's no higher a priority than understanding sets.ml. Still, it would be nice 
to rewrite the parts of sets.ml I use in miz3, including this.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

I made real progress on my set theory problem, but I'd like to do even better.  
My 3860 lines of miz3 Hilbert axiomatic geometry code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
 now uses set abstraction to define rays: 

let Ray_DEF = new_definition
  `! A B. ray A B = {X:point | ~(A = B) /\ Collinear A B X /\ A NOTIN open 
(X,B)}`;;

This works because of the theorem I then prove, following sets.ml

let IN_Ray = prove
 (`! A B X:point. X IN ray A B <=> ~(A = B) /\ Collinear A B X /\ A NOTIN open 
(X,B)`,
  REWRITE_TAC[IN_ELIM_THM; Ray_DEF]);;

I then replaced every occurrence of `IN, Ray_DEF' with the sets.ml-friendly 
`IN_Ray'.  I have no idea why IN_Ray works, and I borrowed code from sets.ml:

let UNION = new_definition
  `s UNION t = {x:A | x IN s \/ x IN t}`;;

let IN_UNION = prove
 (`!s t (x:A). x IN (s UNION t) <=> x IN s \/ x IN t`,
  REWRITE_TAC[IN_ELIM_THM; UNION]);;

This is partly explained on p 91--92 of the HOL Light tutorial:

   In order to eliminate the set abstraction from a term of the form
   x ∈ {t | p}, rewrite with the theorem IN_ELIM_THM [of sets.ml], which will
   nicely eliminate the internal representation of set abstractions, e.g.

   # REWRITE_CONV[IN_ELIM_THM]
   ‘z IN {3 * x + 5 * y | x IN (:num) /\ y IN (:num)}‘;;
   val it : thm =
   |- z IN {3 * x + 5 * y | x IN (:num) /\ y IN (:num)} <=>
   (?x y. (x IN (:num) /\ y IN (:num)) /\ z = 3 * x + 5 * y)

The tutorial then explains {A, B} is syntactic sugar for A INSERT B INSERT {}. 
INSERT is defined in sets.ml as 

let INSERT_DEF = new_definition
  `x INSERT s = \y:A. y IN s \/ (y = x)`;;

That kinda sounds like saying a set abstraction is a lambda, but that can't be, 
because p 100 of the HOL Light tutorial says something I need to understand:

   Since MESON’s handling of lambdas is a bit better than its handling
   of set abstractions,

If anyone can explain any of these mysteries, I'd be happy to listen.  But what 
I'd really like is a way to prove IN_Ray in miz3.  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Now that the Platonism discussion has died down (didn't Russell's paradox show 
the Platonic world of forms doesn't exist?), let me repeat two requests for 
help, as I should be done in 2 or 3 weeks. I have 3700 lines of miz3 code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
and I'm 2 pages away from formalizing the first 7 sections of my geometry paper 
http://www.math.northwestern.edu/~richter/hilbert.pdf
I'm up to Euclid's Prop I.18, and I'll go no higher than Prop I.31.  My paper 
needs a lot of revision now.

My main problem is that I don't understand HOL, so I don't know what theorems 
HOL Light is proving for me.   The HOL4 Logic manual looks like a very 
respectable CS document, but I haven't been able to read it yet, and it's not a 
HOL Light document.   With my Tarski code, I would be happy to say (though I 
don't quite understand it) that HOL Light was verifying my FOL proofs using 
Tarski's geometry axioms.  But there's real  HOL in my Hilbert code funneled 
through sets.ml.  Of course I know what results I meant to prove, and my 
results use sets as mathematicians customarily use sets.  I figure that's the 
result that HOL Light proved for me, but I'm missing the translation.  A simple 
example of a result of mine I can't translate from math to HOL Light is 
OriginInRay_THM below, which leads me into my next problem:

John promised to write some set theory that miz3 can't handle after I finished 
formalizing my plane geometry.  I can live without it, but it would be nice to 
be able to fix something.  In the following 75 lines of miz3 code, everything 
works fine, including my set theoretic definition 
Ram_DEF : thm =
  |- !A B. ram A B = {X | ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)}
except for a timeout error on my last thm.  No problems arise with the funny 
set theoretic definition 
Ray_DEF : thm =
  |- !A B X. ray A B X <=> ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)

-- 
Best,
Bill 

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;; 
timeout := 30;;

new_type("point",0);;
new_type_abbrev("point_set",`:point->bool`);;
new_constant("Between",`:point->point->point->bool`);;
new_constant("Line",`:point_set->bool`);;
parse_as_infix("NOTIN",(11, "right"));;

let NOTIN = new_definition
  `!a:A l:A->bool. a NOTIN l  <=> ~(a IN l)`;;

let Interval_DEF = new_definition
  `! A B X. open (A,B) X <=> Between A X B`;;

let Collinear_DEF = new_definition
  `Collinear A B C  <=> 
  ? l. Line l /\  A IN l /\ B IN l /\ C IN l`;;

let B1 = new_axiom
  `! A B C. Between A B C ==> ~(A = B) /\ ~(A = C) /\ ~(B = C) /\ 
Between C B A /\ Collinear A B C`;;

let B1' = thm `;
  ! A B C.  B IN open (A,C) ==> ~(A = B) /\ ~(A = C) /\ ~(B = C) /\ 
 B IN open (C,A) /\ Collinear A B C
  by IN, Interval_DEF, B1`;;

let I1 = new_axiom
  `! A B.  ~(A = B) ==> ?! l. Line l /\  A IN l /\ B IN l`;;

let Ray_DEF = new_definition
  `! A B X. ray A B X <=> ~(A = B) /\ Collinear A B X /\ A NOTIN open (X,B)`;;

let OriginInRay_THM = thm `;
  let O Q be point;
  assume ~(Q = O) [H1];
  thus O IN ray O Q

  proof
O NOTIN open (O,Q) [OOQ] by B1', NOTIN;
consider l such that 
Line l /\ O IN l /\ Q IN l by H1, I1;
Collinear O Q O by -, Collinear_DEF;
  qed by H1, -, OOQ, IN, Ray_DEF`;;


let EndpointInRay_THM = thm `;
  let O Q be point;
  assume ~(Q = O) [H1];
  thus Q IN ray O Q

  proof
O NOTIN open (Q,Q) [notOQQ] by B1', NOTIN;
consider l such that 
Line l /\ O IN l /\ Q IN l by H1, I1;
Collinear O Q Q by -, Collinear_DEF;
  qed by H1, -, notOQQ, IN, Ray_DEF`;;


let Ram_DEF = new_definition
  `! A B. ram A B = {X:point | ~(A = B) /\ Collinear A B X /\ A NOTIN open 
(X,B)}`;;

let OriginInRam_THM = thm `;
  let O Q be point;
  assume ~(Q = O) [H1];
  thus O IN ram O Q

  proof
O NOTIN open (O,Q) [OOQ] by B1', NOTIN;
consider l such that 
Line l /\ O IN l /\ Q IN l by H1, I1;
Collinear O Q O by -, Collinear_DEF;
  qed by H1, -, OOQ, IN, Ram_DEF`;;

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

I'm going to consider the matter settled: the real miz3, with timeout = -1, was 
not weakened by John & Freek.   They did not desire to restrict the miz3 "by" 
to small inference leaps.   Arguing that the default timeout of 1 is an 
intentional weakness has a certainly logical correctness, but it's like saying 
beer companies intentionally weaken their beer, because in its default state, a 
beer bottle is useless, and requires a special tool (bottle opener) to obtain 
value from it.  

Up to almost 3600 lines of miz3 Hilbert axiomatic geometry 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
just finished Euclid's Proposition I.16 the Exterior Angle thm.  

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Freek, I just caught myself making a big inference leap that I didn't intend.  
The line below 

F NOTIN l [notFl] by l_line, Distinct, I1, Collinear_DEF, Fexists, 
NOTIN;
is a bug on my part.  I meant to write 
F NOTIN l [notFl] by l_line, Cl, Collinear_DEF, -, NOTIN;

Miz3 justified my first buggy line with a 547,963 MESON solved at number, and 
it took me a while to see how MESON did it.  Here's the miz3 proof of an easy 
result, Euclid's Proposition I.11: you can push a perpendicular off a line:

let EuclidProp11_THM = thm `;
  let A B be point;
  assume ~(A = B)   [notAB];
  thus ? F. Right (angle A B F)

  proof
consider l such that 
Line l /\ A IN l /\ B IN l [l_line] by notAB, I1;
consider C such that
B IN open (A,C) /\ seg B C === seg B A [ABC] by notAB, SEGMENT, 
C1OppositeRay_THM;
C IN l [Cl] by l_line, -, BetweenLinear_THM;
~(A = B) /\ ~(A = C) /\ ~(B = C) /\ Collinear A B C [Distinct] by ABC, 
B1';
seg B A === seg B C [BAeqBC] by -, SEGMENT, ABC, C2Symmetric;
consider F such that
~Collinear A F C  /\  seg F A  === seg F C [Fexists] by Distinct, 
IsoscelesExists_THM;
F NOTIN l [notFl] by l_line, Distinct, I1, Collinear_DEF, Fexists, 
NOTIN;
~Collinear B F A /\ ~Collinear B F C [BFAncol] by l_line, Cl, Distinct, 
I1, Collinear_DEF, -, NOTIN;
~Collinear A B F /\ Angle (angle A B F) [angABF] by -, 
CollinearSymmetry_THM, ANGLE;
angle A B F Suppl angle F B C [ABFsuppl] by -, ABC, 
SupplementaryAngles_DEF;
~(B = F) by l_line, notFl, NOTIN;
seg B F === seg B F by -, SEGMENT, C2Reflexive;
B,F,A cong B,F,C by BFAncol, -, BAeqBC, Fexists, SSS_THM;
angle A B F === angle F B C by -, TriangleCong_DEF, AngleSymmetry_THM;
  qed by angABF, ABFsuppl, -, RightAngle_DEF`;;

All I needed was to say that  A, F & C are noncollinear (Fexists), so there 
can't be any line containing the three (Collinear_DEF)  A & C already belong to 
l (l_line, Cl), so if F belongs to l as well, A, F & C would be collinear, and 
that's a contradiction.  MESON does such proofs by contradiction just fine.  
That's the line I should have written:
F NOTIN l [notFl] by l_line, Cl, Collinear_DEF, -, NOTIN;
But I wrote buggily
F NOTIN l [notFl] by l_line, Distinct, I1, Collinear_DEF, Fexists, 
NOTIN;
I think I see how miz3 get a proof out of this nonsense I wrote: 

A & B are distinct points on l (l_line, Distinct), and so there is only one 
line containing A & B (I1).  Since 
A, B & C are collinear (Distinct), C must belong to this line l as well 
(Collinear_DEF), and now we can use the proof I meant above.   Maybe this leap 
isn't that huge.  But I certainly didn't intend it, and it took me a while to 
figure out how miz3 could have made sense of it.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Michael, this is a discussion of motivation.  My desire is for miz3 to become 
stronger, so I can take bigger inference leaps that will take less time.  That 
would be pointless if John & Freek's desire was that miz3 be ``less able to 
prove goals,'' as you did not quite say.  So I've tried to argue that John & 
Freek had no such desire.  Freek clarified my point:

   [...] the main point was that if an inference is _not_ correct,
   often MESON will run for the full timeout time.  So checking proofs
   with errors (= all proofs when you're not finished yet) gets very
   slow, and without timeout close to infinite.  The timeout thing is
   just to deal with that.

This is especially important for beginners.  I still make plenty of errors, but 
they are errors that I understand, thanks to Freek's private lessons.  When I 
first started with miz3, I not only made more errors, I didn't understand what 
I was doing wrong.  (Mizar, which seems to desire users to be ``less able to 
prove goals,'' has much better error messages than miz3.)  So it would have 
been senseless for me to try to take big inference leaps when I started.  Now 
I'm more confident, and take bigger inference leaps, and use timeout := 30;;.  

Freek didn't give miz3 enough credit above.  Checking an unfinished proof with 
a large timeout isn't necessarily slow.  Miz3 can often quickly spot that you 
don't have a proof and give you a #1 inference error.  miz3 is only slow when 
you have a "by" justification that makes pretty good sense, and MESON works 
hard to prove that line.  

Some numbers may help.  On a Linux box with a  2.4GHz processor and 4 GB RAM, 
my miz3 code 
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
takes almost 5 minutes to run, and I have 41 6-digit MESON "solved at" numbers. 
 Here's my highest:
[...]  
0..0..5..21..53..106..233..490..909..1725..3233..5819..10297..17188..26577..40416..67880..107813..185180..291684..445461..solved
 at 547963
[...]  val EuclidProp11_THM : thm = |- !A B. ~(A = B) ==> (?F. Right (angle A B 
F))

I'm just proving that we can push a perpendicular off a line. I know which line 
of the proof earned the half-million MESON "solved at" number:
F NOTIN l [notFl] by l_line, Distinct, I1, Collinear_DEF, Fexists, 
NOTIN;

I  actually have a bug in my code, and I'm surprised miz3 justified this at 
all!  I'll discuss that in a separate post, but what I meant to write was 
  F NOTIN l [notFl] by l_line, Cl, Collinear_DEF, -, NOTIN;
and miz3 justifies that with a solved at number of 49, I think.  But lets move 
on to 

how my HOL may be impeding MESON's efforts.  I don't actually know which parts 
of my code are HOL.  My first line of code is 
new_type("point",0);;
which I think is HOL, and means take a set called point.  In that sense, I'm 
doing HOL, right?  I did that in my Tarski code too.  But it gets worse:
new_type_abbrev("point_set",`:point->bool`);;
new_constant("Line",`:point_set->bool`);;

So basically point_set = P(point), as sets are identified (or confused) with 
boolean functions, and I'm saying there is a boolean function Line defined on 
P(point), which is supposed to tell whether a set of points actually forms a 
line.  That sounds like HOL.  More crucial I think is my constant use of IN, 
defined in sets.ml as 
let IN = new_definition
  `!P:A->bool. !x. x IN P <=> P x`;;
Everyone says that MESON can't do HOL, and I wonder if MESON can understand me 
when I use IN.   My first definition is in fact about IN:
let NOTIN = new_definition
  `!a:A l:A->bool. a NOTIN l  <=> ~(a IN l)`;;

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Freek Wiedijk]

Hi Michael,

Okay, final mail I'm sending about this:

>1. miz3's "by" is designed (i.e., someone intentionally
>chose to do this) with a time limit.

Well, the time limit even is there if you put a tactic there
yourself.  So I would distinguish between the default "by"
prover, and the time limit thing.  But apart from that: yes.

>2. The time limit means that miz3's "by" proves fewer
>goals than it might without the time limit.

Yes.  Although in practice it won't be so different.
A justification failing because of the time limit is rare.
Generally it means that it just doesn't hold.

>3. A system A that proves fewer things than system B is a
>"weaker" system than B.

Yes!

>4. So, miz3 is intentionally weakened.

There's no flaw in your logic :-)  I fully agree.

Freek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Freek Wiedijk]

Hi Bill,

>Thus, I conclude that the purpose of the default timeout
>isn't to weaken miz3, but to better instruct beginners

Ah no, the main point was that if an inference is _not_
correct, often MESON will run for the full timeout time.
So checking proofs with errors (= all proofs when you're
not finished yet) gets very slow, and without timeout close
to infinite.  The timeout thing is just to deal with that.

I think the original Automath from the seventies had
exactly the same feature.  Typechecking in type theory _is_
decidable, but if things are type incorrect, in Automath it
takes forever to establish this (because it will endlessly
unfold all definitions: Automath didn't have opaqueness.)

Freek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Freek Wiedijk]

Hi Bill,

>Can you jump into the discussion Michael and I were having
>about whether miz3 is intentionally weakened?  Michael seems
>to think yes, I think no, but I wonder what effect the MESON
>depth limit of 50 has, or the fact that MESON is just FOL
>and not HOL.

Ah no, there were no deep thoughts behind the choice of "by"
in miz3.  I just chose the most trivial option available
(well, also I wanted it to be at least as strong as the
real Mizar "by"...  which it isn't, because you lack the
properties and requirements.)

As I wrote before, I think the thing actually is "bad",
because often you can justify a proof step with a REWRITE_TAC
that only does a very small number of rewrites, but not
with the default "by".  That feels very strange.

Implementing a better "by" for miz3 is a nice project to
think about, but it's not on the top of the stack of things
I'm currently considering doing.

Freek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 08/08/12 16:45, Bill Richter wrote:
>> My claim [on whether miz3 is "intentionally weakened"] is based on my
>> believing that miz3 imposes a time limit,

> Thus, I conclude that the purpose of the default timeout isn't to weaken
> miz3, but to better instruct beginners who, if I'm a representative example,
> make scores of obvious errors and need immediate feedback :)

I hesitate to speculate about motivation.  However, if you're right, it's clear 
that the goal of instructing beginners is well-served by deliberately weakening 
miz3 so that it is less able to prove goals.

Here's my last attempt.

1. miz3's "by" is designed (i.e., someone intentionally chose to do this) with 
a 
time limit.

2. The time limit means that miz3's "by" proves fewer goals than it might 
without the time limit.

3. A system A that proves fewer things than system B is a "weaker" system than 
B.

4. So, miz3 is intentionally weakened.

Why are we debating this again?

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

   That is a function of type term -> thm, so will enable you to
   "test" terms' behaviours.  The more definitions you put into the
   list passed to REWRITE_CONV, the more you will get out.

Thanks, Michael! I see your REWRITE_CONV is heavily discussed in sec 7.4 
Rewriting of the HOL Light tutorial.  I should work every example in the 
section.  I would not have guessed what you said, so thanks again.

   My claim [on whether miz3 is "intentionally weakened"] is based on
   my believing that miz3 imposes a time limit, 

Freek boldly tells folks to increase the time limit.  I use 
timeout := 30;;
and Freek posted here not long ago, I believe, that 
timeout := -1;;
means there is no time limit.  I complained to Freek about something and he 
told me to try 
timeout := 10;;
as if that would take forever.  I've learned to find other things to do while 
I'm waiting for miz3 to evaluate my code.  I don't just sit there and watch the 
screen anymore, and I'm grateful for Freek's caching, which means "the 2nd time 
around" there's no MESON calculations.

Thus, I conclude that the purpose of the default timeout isn't to weaken miz3, 
but to better instruct beginners who, if I'm a representative example, make 
scores of obvious errors and need immediate feedback :)

   and that there is a depth limit in MESON more generally 

Yes, but that has nothing to do with miz3.  As the HOL Light reference manual 
says, 

   Normally MESON, MESON_TAC and ASM_MESON_TAC explore the search space
   by successively increasing a size limit from 0, increasing it by 1 per
   step and giving up when a depth of 50 is reached. The more general
   tactic GEN_MESON_TAC allows the user to specify the starting,
   finishing and stepping value, but is otherwise identical to
   ASM_MESON_TAC. In fact, that is defined as:

 # let ASM_MESON_TAC = GEN_MESON_TAC 0 50 1;;

Normally, the defaults built into MESON_TAC and ASM_MESON_TAC are
reasonably effective. However, very occasionally a goal exhibits a
small search space yet still requires a deep proof, so you may
find GEN_MESON_TAC with a larger ``maximum'' value than 50
useful. Another potential use is to start the search at a depth
that you know will succeed, to reduce the search time when a proof
is re-run. However, the inconvenience of doing this is seldom
repaid by a dramatic improvement in performance, since exploration
is normally at least exponential with the size bound.

I think it's clear that John isn't trying to put shackles on miz3 with the 
MESON timeout.  I don't have a clue about this depth biz, or whether I'd be 
better off with a larger depth limit than the default of 50.  

   Both of these things will stop miz3's "by" from proving things that
   it might otherwise.  Hence it is "intentionally weakened".

I respectfully submit that you have not made your case.

   That weakening then helps to limit the size of the inference jumps
   you can make.  I do not think this is a bad thing.

The default timeout, which I can't live with, definitely limit the size of the 
inference jumps.  But you taught me that such limits are a bad thing, or more 
precisely, it's playing an unwinnable game to monkey with the heuristics to 
shackle the proof assistant.  You're the one who got me out of the 
Mizar-in-the-classroom game of counting on proof assistant weakness in order to 
police the students' homework.  I am very grateful to you, Michael, for curing 
me of this, and you may recall it took you many emails.  It's hard to give up 
control, but respect for your students may require it, as in,  "If you're more 
interested in exploring the proof assistant than in writing up a `complete' 
geometry proof, maybe you're on the right track!"

BTW I'm near 3600 lines of my miz3 Hilbert geometry code
http://www.math.northwestern.edu/~richter/RichterHOL-LightMiz3HilbertAxiomGeometry.tar.gz
and just proved Euclid's Prop I.12, which Euclid used advanced circle 
techniques to prove, and Greenberg skipped some important steps of:

DropPerpendicularToLine_THM : thm =
  |- !P l.
 Line l
 ==> P NOTIN l
 ==> ?A D. A IN l /\ D IN l /\ Right (angle P D A)

It's really improving my understanding to code up these miz3 proofs.  Greenberg 
has a nice proof (Prop. 3.16) which I saw no problem with until I tried to 
formalize it.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 08/08/12 11:21, Bill Richter wrote:

> Thanks, Michael!  HOL Light does not have your EVAL, but maybe it has
> something similar.   EVAL is indeed the sort of thing that Colin Rowat and I
> were looking for.  I did read a bit about rewriting, and I see that it's in
> the EVAL ballpark, but it sounds like you have to be pretty good at HOL Light
> to use it.  Any tip?

The first point of entry is probably REWRITE_CONV [my_definition_thm].

That is a function of type term -> thm, so will enable you to "test" terms' 
behaviours.  The more definitions you put into the list passed to REWRITE_CONV, 
the more you will get out.

> Can you jump into the discussion Michael and I were having about
> whether miz3 is intentionally weakened? Michael seems to think yes,
> I think no, but I wonder what effect the MESON depth limit of 50
> has, or the fact that MESON is just FOL and not HOL.

My claim is based on my believing that miz3 imposes a time limit, and that 
there 
is a depth limit in MESON more generally (perhaps I'm wrong about these).  Both 
of these things will stop miz3's "by" from proving things that it might 
otherwise.  Hence it is "intentionally weakened".

That weakening then helps to limit the size of the inference jumps you can 
make. 
  I do not think this is a bad thing.

The fact that MESON is FOL and not HOL will probably make it unable to prove 
theorems like

   EVERY (\x. P (f x y)) [a; b; c]

where EVERY is the (higher-order) function that checks that all elements of a 
list satisfy the predicate that is passed as EVERY's first argument.

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

   You check that your definition is correct by proving appropriate
   theorems about it.  For example, HOL4 provides an EVAL function so
   that you can do things like

  > EVAL ``FACT 20``;
  val it = |- FACT 20 = 243290200817664: thm

   and this is the sort of thing you'd like to see.  In HOL Light, you
   could certainly use rewriting to prove this sort of result.

Thanks, Michael!  HOL Light does not have your EVAL, but maybe it has something 
similar.   EVAL is indeed the sort of thing that Colin Rowat and I were looking 
for.  I did read a bit about rewriting, and I see that it's in the EVAL 
ballpark, but it sounds like you have to be pretty good at HOL Light to use it. 
 Any tip? 

Freek, I was disappointed to not learn how to write readable code in Isar, as 
Isabelle has great fonts and lots of respectable looking documentation.   And 
on top of that Makarius wrote me 100 lines of code.  But I couldn't figure out 
how to write readable proofs there.  So I'm sticking with Mizar and your 
excellent miz3.   Can you jump into the discussion Michael and I were having 
about whether miz3 is intentionally weakened?  Michael seems to think yes, I 
think no, but I wonder what effect the MESON depth limit of 50 has, or the fact 
that MESON is just FOL and not HOL.

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Ramana Kumar]

On Tue, Aug 7, 2012 at 1:19 PM, Freek Wiedijk  wrote:
> Also, does anyone know what is the status of Mohan
> Ganesalingam's work in this direction (see for example
> )?

No, but we can ask him :) (CC'ed)
Context: http://sourceforge.net/mailarchive/message.php?msg_id=29635641,
http://sourceforge.net/mailarchive/message.php?msg_id=29644387.
By the way, the page one level up, http://people.pwf.cam.ac.uk/mg262/,
has his thesis and other good stuff.

>
> Freek
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Freek Wiedijk]

Hi Bill,

>Why are miz3 and Mizar the only proof assistants where
>one can easily write up human readable proofs?

I'm surprised you're not including Isar in this list!

And do you know about ForTheL (see
)?  Now _there's_
a readable formal language! :-)

Also, does anyone know what is the status of Mohan
Ganesalingam's work in this direction (see for example
)?

Freek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Makarius]

On Sun, 5 Aug 2012, Konrad Slind wrote:

> My opinion is that Peter Homeier's HOL-Omega is the right setting to 
> properly implement something locale-like, since it provides 
> quantification over type variables in the logic. In plain old HOL the 
> implementation of locales as essentially assumptions on goals is too 
> limiting for polymorphism.

In the 1.5 decades refining Isabelle locales, we have separated these two 
concerns: (1) management of local contexts and definitional specifications 
wrt. local contexts, (2) logical foundations for building actual abstract 
contexts.

(1) is the infrastructure, consisting of quite a bit of abstract 
non-sense.  It is now called "local theory" in Isabelle.  It provides some 
interfaces for definitions in a local context, where the results are 
polymorphic in the sense of Hindley-Milner, but some types may remain 
fixed according to the context.

(2) are concrete implementations of locales, type classes, type-class 
instantiation, unrestricted overloading etc.  This could cover other 
concepts for modular theories using facilities of HOL-Omega, or external 
theory interpretation as in Isabelle/AWE from Bremen.


Both (1) and (2) are difficult to implement.  We are still working on 
various fine points concerning local syntax (via notation or abbreviation) 
that moves between such local contexts.  Another challenge that I have 
boldly revisited this year is to allow nesting of locale-like contexts.

What is also difficult to get right are declarations for proof tools 
associated with theorems produced in abstract situations, when they start 
moving around to other contexts.  E.g. ways to manage "simpset"-like 
containers in conformance to abstract theories and their interpretations 
by concrete instances.

Type classes have turned out an important special case for all that, 
because the abstraction looks "concrete", via polymorphic constants with 
some specific type constraints.  Syntax and tool declarationas are often 
stable wrt. type-instantiation of class constants, without further ado.


Makarius

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Michael Norrish]

On 06/08/12 15:01, Bill Richter wrote:
> Your type_of `MAP`;; was
> plenty illuminating, that's how I figured out what polymorphism meant, with
> the Scheme analogy, but I'm confused.  On p 350 of
> http://www.cl.cam.ac.uk/~jrh13/hol-light/reference.pdf it explains lower-case

> map: map : ('a -> 'b) -> 'a list -> 'b list

> Are you saying this is an Ocaml function, and not something we can use in HOL
> Light?

You can't use it inside the logic; but you can use it in the HOL interactive 
loop.  Recall that there are two languages here: the language of the logic 
(where you define cong, for example), and the implementation (or meta) 
language, ML.

When you type

   type_of `MAP`

you are applying an ML function, type_of, to the term `MAP`.  At the ML level, 
type_of has type

   :term -> type

and `MAP` has type :term.  Within the logic, `MAP` has type (A -> B) -> A list 
-> B list.

> A few pages later is MAP_EVERY : ('a -> tactic) -> 'a list -> tactic
> That certainly sounds like HOL Light.

That's certainly HOL Light, but it's not a function in the HOL Logic.

> There is no MAP in reference.pdf.

Indeed; the reference lists ML functions, not those that are defined within the 
logic.

> This brings up a question Colin Rowat was asking earlier: if you define
> various vector-related functions in HOL Light (like the maximum of a vector,
> or the dot product of two vectors...), how can you check if your code is
> working?  Is there some cooperation between ML and HOL that I'm missing?
> Obviously HOL is coded up in ML, but are you supposed to mix freely ML and
> HOL code somehow?

No.  You check that your definition is correct by proving appropriate theorems 
about it.  For example, HOL4 provides an EVAL function so that you can do 
things 
like

   > EVAL ``FACT 20``;
   val it = |- FACT 20 = 243290200817664: thm

and this is the sort of thing you'd like to see.  In HOL Light, you could 
certainly use rewriting to prove this sort of result.

(Think about what EVAL's type is.  It's another ML function, and it has type 
:term -> thm.  FACT, on the other hand, is a logic function, with type :num -> 
num.)

Michael

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] rigorous axiomatic geometry proof in HOL Light

[Bill Richter]

Thanks, Michael, I'll try out your cong trick.  Your type_of `MAP`;; was plenty 
illuminating, that's how I figured out what polymorphism meant, with the Scheme 
analogy, but I'm confused.  On p 350 of
http://www.cl.cam.ac.uk/~jrh13/hol-light/reference.pdf
it explains lower-case map:
map : ('a -> 'b) -> 'a list -> 'b list
Are you saying this is an Ocaml function, and not something we can use in HOL 
Light?  A few pages later is 
MAP_EVERY : ('a -> tactic) -> 'a list -> tactic
That certainly sounds like HOL Light.  There is no MAP in reference.pdf.  This 
brings up a question Colin Rowat was asking earlier: if you define various 
vector-related functions in HOL Light (like the maximum of a vector, or the dot 
product of two vectors...), how can you check if your code is working?  Is 
there some cooperation between ML and HOL that I'm missing?  Obviously HOL is 
coded up in ML, but are you supposed to mix freely ML and HOL code somehow?

-- 
Best,
Bill 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info