There is not much information on how the software works (it’s written in Haskell btw.), but one stands out for me:

One thing that humans do not do is rewrite all their statements in low-level language and work directly from the axioms of set theory. So our program doesn’t do that either.

So this is not a tool for formalized mathematics. I have always considered such attempts of doing mathematics on a computer that try to emulate the way humans think and are not based on solid formal foundations as a dead end. However after some thinking I do see that the software may have useful applications the same way Computer Algebra Systems have.  In its ultimate form the program would be equipped with a large data base of mathematical facts (the CYC style) and perhaps a modular library of tactics (for the lack of better word) that emulate various approaches humans apply to solving problems. Using that, the program  will be able to rapidly search for proofs that may or may not be entirely correct, but still very convincing for humans. There will be two sources of correctness errors. First of all without formal foundation the meaning of the facts in the database will be fuzzy. Second, if the facts in the database are input by humans they may be syntactically OK (that can be checked by the machine), but semantically wrong. People just make mistakes and the number of such mistakes can be reduced only by a an extensive human review process which would be very costly to set up on a larger scale. Most of the errors will be easy to spot, because the program can write proofs in a clear style that is easier for a reviewer to check. However, some errors can be very difficult to notice since generally the proofs will sound convincing (a design goal) and almost all of them will be correct.

Of course the hope is that the program can be used not only by undergraduate math majors cheating with their homework, but also by serious researches trying to come up with new theorems. I still think that the chances for that are rather small.

As for myself, I have finished the proof that the function is continuous in the natural topology on the space of -element sequences of a topological group.

What I liked about Scala

I don’t want to write about all the advantages of Scala. After a small project I don’t think I have anything meaningful to add to the things other people have written. It’s a functional language. It feels like Haskell – if it compiles, it most likely runs OK.  I was amazed by the type system – supporting both  Java classes and functional programming in a Haskell-like statically typed language and not running into some fundamental show-stoppers is quite incredible. I used IntelliJ IDE to write the code and after overcoming the initial Maven integration problems it worked fine. It’s the first time I worked with Java style IDE and I liked all the help it gives. The compilation times were long, but IDE checks syntax on the fly, so there is no need to build something just to see if it builds.

What I didn’t like about Scala

Nothing specifically about Scala. It was my first encounter with programming in the Java world. I got a general sense of bloat and fragility. More than half of the time I was struggling with configurations and set ups – IntelliJ, Maven, Jenkins, Artifactory and interactions between all that. Some of the problems could have been the result of my lack of experience, some was due to Scala being somewhat nonstandard for those tools, so it was more difficult to find solutions on the web. Another problem I had was a different idea on the tradeoff between writing your own code and using an external library to do things.

So why “probably not”?

In my evaluation I looked both at success and failure stories (which not surprisingly were more difficult to find). I think evaluating possibility of switching the development to Scala management may make two mistakes. One is thinking that this is a technical problem – they try to identify problem domains where “Scala is best” and since what the company makes fits the advertised Scala strengths (large scale, concurrent, Java legacy code etc) they hope that Scala will bring gains in productivity. I think the main criterion for taking the risk of switching to Scala should not be the kind of software you write but the kind of developers team you have. The second mistake is made by people who understand that this is a people problem, but think that since they have very talented and experienced Java developers (or are planning to hire such), they should be OK. Here is the heart of the problem:

Scala is not a better Java, it’s an ML for JVM

If you don’t know what I mean here, that’s probably what I mean.

The problem is a bit wider than Java vs. Scala. It’s more like imperative vs. functional programming. I believe OO and imperative programming is fundamentally closer to the natural way human brains are wired. To feel comfortable with functional programming one has to either have a (rare) natural talent for this particular abstraction or have a brain warped by years of training (in mathematics for example like myself). This is one of those barriers that are invisible for people who are on the other side of them. This is the main reason why functional programming languages are so dominated by imperative ones in all popularity statistics.

An alternative view is that the only reason most people find it easier to formulate algorithms in the imperative way is that this is what they first encountered in their education. If their first programming language was functional, then we would see the opposite result. I admit that this imprinting effect may exist to some degree, but I don’t think it is important. I would have to see a well designed experiment to change my opinion.

I have seen opinions that the difficulty of switching to the functional style is something that happens to “average” programmers. For good, smart and eager to learn ones functional programming is natural. I think this is an illusion. In fact, very experienced and productive Java programmers have even more reasons to resist the switch, especially if it is unilaterally imposed by the management.

So what kind of a team will benefit from switching to Scala and when this will most likely lead to failure? There is one good proxy criterion: if the team wants Scala, they will like it and there is a good chance for success. If the switch is something that they have to do because of a management decision, there is a high probability of failure.

So, may recommendation was “Scala? Probably not, at least not now”. I have a little bit of hope that it will be ignored and I will get to have fun with Scala some day again.

1. Download Isabelle. The installation is just unpacking to the directory of your choice, I unpacked it to ~/bin. That created a directory ~/bin/Isabelle2012.

2. Edit ~/bin/Isabelle2012/etc/settings file to change the default logic to ISABELLE_LOGIC=ZF.

3. Run “build ZF” in the ~/bin/Isabelle2012 directory. This builds the ZF heap image. Isabelle ships with only HOL image precompiled.

4. Install openjdk-6-jre, texlive-latex-base and texlive-latex-extra packages. It’s the first time I am using openjdk instead of Sun Java, but so far I haven’t noticed any issues. The texlive-latex-extra package is for comment.sty file that is needed for LaTeX processing of proof documents.

5. Start Isabelle jEdit interface with  ~/bin/Isabelle2012/bin/isabelle jedit and correct the font size in Utilities/Global Options/jEdit/Text Area/Text font. Isabelle ships with the font size 18.

That’s pretty much all that is needed to have Isabelle ready for IsarMathLib contributions.

Update Aug 10th 2012: Turns out installing Java is not necessary as the bundle already contains a suitable JDK.

I downloaded the tar file and played a bit with the contents. The amount of work that went to the Russell project is staggering: almost 60000 lines of GPL licensed C++ code (very nicely written, btw) and 3800 lines of shell scripts. The scripts mostly do tests described on the Russell page. The compression test in particular is very interesting – it decompiles Metamath proofs to Russel and then tries to reduce them to the minimal number of steps from which the full Metamath proof can be restored with the prover. I run the compression test on the full Metamath database (included in the Russel’s distribution) with the recommended parameter N=300 (meaning that one in 300 proofs will be compressed). The results were not that amazing – out of 40 proofs for which the compression was attempted, only in two cases the prover managed to reduce the number of steps. In one case the length of the proof was reduced from 8 to 7 steps and in the other case from 12 to 4.
For the second case the original decompiled theorem looks like this:

theorem eqfnfvf2 (var x : set , var y : set , var A : class , var F : class , var G : class )
{
hyp 1 : wff = |- ( ( y ∈ F ) → ∀ x ( y ∈ F ) ) ;
hyp 2 : wff = |- ( ( y ∈ G ) → ∀ x ( y ∈ G ) ) ;
-----------------
prop : wff = |- ( ( ( F 𝐅𝐧 A ) ∧ ( G 𝐅𝐧 A ) ) → ( ( F = G ) ↔ ∀ x ∈ A ( ( F ` x ) = ( G ` x ) ) ) ) ;
}
proof /*  [22-Mar-2009]  */ /*  [29-Jan-2004]  */ {
var z : set ;
step 1 : wff = theorem eqfnfv2 () |- ( ( ( F 𝐅𝐧 A ) ∧ ( G 𝐅𝐧 A ) ) → ( ( F = G ) ↔ ∀ z ∈ A ( ( F ` z ) = ( G ` z ) ) ) ) ;
step 2 : wff = axiom ax-17 () |- ( ( y ∈ z ) → ∀ x ( y ∈ z ) ) ;
step 3 : wff = theorem hbfv (hyp 1, step 2) |- ( ( y ∈ ( F ` z ) ) → ∀ x ( y ∈ ( F ` z ) ) ) ;
step 4 : wff = axiom ax-17 () |- ( ( y ∈ z ) → ∀ x ( y ∈ z ) ) ;
step 5 : wff = theorem hbfv (hyp 2, step 4) |- ( ( y ∈ ( G ` z ) ) → ∀ x ( y ∈ ( G ` z ) ) ) ;
step 6 : wff = theorem hbeq (step 3, step 5) |- ( ( ( F ` z ) = ( G ` z ) ) → ∀ x ( ( F ` z ) = ( G ` z ) ) ) ;
step 7 : wff = axiom ax-17 () |- ( ( ( F ` x ) = ( G ` x ) ) → ∀ z ( ( F ` x ) = ( G ` x ) ) ) ;
step 8 : wff = theorem fveq2 () |- ( ( z = x ) → ( ( F ` z ) = ( F ` x ) ) ) ;
step 9 : wff = theorem fveq2 () |- ( ( z = x ) → ( ( G ` z ) = ( G ` x ) ) ) ;
step 10 : wff = theorem eqeq12d (step 8, step 9) |- ( ( z = x ) → ( ( ( F ` z ) = ( G ` z ) ) ↔ ( ( F ` x ) = ( G ` x ) ) ) ) ;
step 11 : wff = theorem cbvral (step 6, step 7, step 10) |- ( ∀ z ∈ A ( ( F ` z ) = ( G ` z ) ) ↔ ∀ x ∈ A ( ( F ` x ) = ( G ` x ) ) ) ;
step 12 : wff = theorem syl6bb (step 1, step 11) |- ( ( ( F 𝐅𝐧 A ) ∧ ( G 𝐅𝐧 A ) ) → ( ( F = G ) ↔ ∀ x ∈ A ( ( F ` x ) = ( G ` x ) ) ) ) ;
qed prop = step 12 ;
}

This gives some idea on the syntax of the Russell language. I would say it is very readable, although it is funny how it resembles C++. Unfortunately the distribution does not provide any sample of human-written Russel code or tutorial on the syntax of the language. The original proof syntax is somewhat similar to what one gets from the SHOW STATEMENT and SHOW PROOF command in Metamath.

MM> SHOW STATEMENT eqfnfvf2
$d x A $.  $d y F $.  $d y G $.  $d x y $.
13784 eqfnfvf2.1 $e |- ( y e. F -> A. x y e. F ) $.
13785 eqfnfvf2.2 $e |- ( y e. G -> A. x y e. G ) $.
13786 eqfnfvf2 $p |- ( ( F Fn A /\ G Fn A ) -> ( F = G <-> A. x e. A ( F ` x )
= ( G ` x ) ) ) $= ... $.

MM> SHOW PROOF eqfnfvf2
39   syl6bb.1=eqfnfv2  $p |- ( ( F Fn A /\ G Fn A ) -> ( F = G <-> A. z e. A (
F ` z ) = ( G ` z ) ) )
77         hbfv.1=eqfnfvf2.1 $e |- ( y e. F -> A. x y e. F )
84         hbfv.2=ax-17      $a |- ( y e. z -> A. x y e. z )
85       hbeq.1=hbfv       $p |- ( y e. ( F ` z ) -> A. x y e. ( F ` z ) )
91         hbfv.1=eqfnfvf2.2 $e |- ( y e. G -> A. x y e. G )
98         hbfv.2=ax-17      $a |- ( y e. z -> A. x y e. z )
99       hbeq.2=hbfv       $p |- ( y e. ( G ` z ) -> A. x y e. ( G ` z ) )
100     cbvral.1=hbeq     $p |- ( ( F ` z ) = ( G ` z ) -> A. x ( F ` z ) = ( G
` z ) )
111     cbvral.2=ax-17    $a |- ( ( F ` x ) = ( G ` x ) -> A. z ( F ` x ) = ( G
` x ) )
138       eqeq12d.1=fveq2   $p |- ( z = x -> ( F ` z ) = ( F ` x ) )
144       eqeq12d.2=fveq2   $p |- ( z = x -> ( G ` z ) = ( G ` x ) )
145     cbvral.3=eqeq12d  $p |- ( z = x -> ( ( F ` z ) = ( G ` z ) <-> ( F ` x
) = ( G ` x ) ) )
146   syl6bb.2=cbvral   $p |- ( A. z e. A ( F ` z ) = ( G ` z ) <-> A. x e. A (
F ` x ) = ( G ` x ) )
147 eqfnfvf2=syl6bb   $p |- ( ( F Fn A /\ G Fn A ) -> ( F = G <-> A. x e. A ( F
` x ) = ( G ` x ) )

After the compression the proof is as follows:

problem eqfnfvf2 (var x : set, var y : set, var A : class, var F : class, var G : class)
{
hyp 1 : wff = |- ( ( y ∈ F ) → ∀ x ( y ∈ F ) ) ;
hyp 2 : wff = |- ( ( y ∈ G ) → ∀ x ( y ∈ G ) ) ;
-----------------
prop : wff = |- ( ( ( F 𝐅𝐧 A ) ∧ ( G 𝐅𝐧 A ) ) → ( ( F = G ) ↔ ∀ x ∈ A ( ( F ` x ) = ( G ` x ) ) ) ) ;
}
proof /*  [22-Mar-2009]  */ /*  [29-Jan-2004]  */ {
var z : set;
step 1 : wff = ? |- ( ( z = x ) → ( ( F ` z ) = ( F ` x ) ) )  ;
step 2 : wff = ? |- ( ( z = x ) → ( ( G ` z ) = ( G ` x ) ) )  ;
step 3 : wff = ? |- ( ( z = x ) → ( ( ( F ` z ) = ( G ` z ) ) ↔ ( ( F ` x ) = ( G ` x ) ) ) )  ;
step 4 : wff = ? |- ( ( ( F 𝐅𝐧 A ) ∧ ( G 𝐅𝐧 A ) ) → ( ( F = G ) ↔ ∀ x ∈ A ( ( F ` x ) = ( G ` x ) ) ) )  ;
qed prop 1 = step 4 ;
}

One can see two differences – the keyword “problem” is used instead of “theorem” and the lack of theorem references in the proof steps. My understanding is that the prover can find the correct references and reconstruct the complete 12 steps Metamath proof from just this sequence of four assertions. That’s very good, but in practice such approach seldom works well as evidenced by the compression statistics. In Isar this works (from the user perspective, I have no idea what happens internally) somewhat differently: there is a certain subset of theorems that are “added to the simplifier” and may be considered by user as common knowledge. To justify a step in a proof the user must reference only the theorems that are needed but are not in the simplifier. So for every step there is a different set of assertions that are used when searching for the proof. This set consists of the theorems in the simplifier, additional references provided by the proof author for this step and the hypotheses of the proof step, that must be either previously proven steps or come from the hypotheses of the theorem. Maybe defining such dynamic proof search space for each proof step is possible in Russell, I dont’ know.
Another feature that in my opinion is important for a formal proof language but seems to be missing in Russell is the structuring of proof. The structure of the Russel proof is linear without the possiblility of creating subproofs for intermediate results. Such feature is a good way to cope with overwhelming amount of detail that is typical for formal proofs and allows a reader to set the amount of detail she wants to be shown by the presentation layer. Again, maybe this is possible in Russel, but there is no example of such syntax in the automatically generated Russell code I looked at.
Judging from hits in search engines the Russell project is abandoned and unused. I think it deserves at least that more people know about it and maybe someone will base his idea or code on Russell.

I am happy to report that I use Isabelle2012 Makarius Wenzel’s  Prover IDE for writing formal math and it works very well for me. A screenshot follows.

An amusing fact that I encountered while proving one of the lemmas was that . Let me explain what this notation means. The expression is the set of functions whose domain is and values belong to . When we write we are using the semicolon instead of the usual symbol to express the fact that the function belongs to that set of functions. In particular  is the set of -valued functions whose domain is the empty set. Well, are there any such functions? In other words is  it true that ? Turns out that the empty set itself satisfies  the definition of what it means to be a function (in ZF) and of course the domain of that function is empty. And who can deny that for all the value of that function on is in whatever? So, really . Since the empty set is the only function whose domain is empty, we get .  And it’s not a typo, because in ZF is the same as the natural number 1.

Usually such facts are only a source of fun and games, but this one actually did get used in a proof of one of the theorems in the theory added in this release. Here is how it came about.

I needed to have the product topology defined on where is (the carrier of) a topological space with topology . Dealing with cartesian products of sets is somewhat inconvenient in Isabelle/ZF, so I decided to use the space of sequences as a proxy for the cartesian product (recall that in ZF if is a natural number, then ). Once we talk about topologies on function spaces, why not just define a topology on where is an arbitrary index set? So this is what I did.

To do that I needed to define a base of that topology on . The standard approach to define a base for a product topology is by taking all finite products of open sets. In the function space approach this corresponds to taking a finite subset and a function whose values are open sets. Then we can define a set in the base as

.

The base is then the collection of all such sets .

Now we want to show that the whole function space is one of the base sets. This corresponds to placing no restrictions on the functions, i.e. we want to have . This way we start thinking what may be.

There was a discussion initiated by James Frank in November last year on the Isabelle mailing list about problems with making mathematics formalized in HOL similar in notation and terminology to the standard (informal) mathematics. The main difficulty here is that standard mathematics uses set theory notation, so obviously something based on type theory has to look different. This lead to a discussion what might be the reasons of doing formalized mathematics in simply typed HOL rather than set theory. Josef Urban expressed the following opinion:

I do not think that there are good pragmatic automation-related reasons for persuading mathematicians to work in HOL instead of ZF. Given the very low penetration that formal mathematics has so far among mathematicians, I think it would not hurt the formal systems to go where the mathematicians are.

with which I fully agree.

In the same thread Steven Obua announced the ProofPeer project – a cloud-based social network interactive theorem proving system. (That is probably the the highest concentration of buzzwords in one sentence that I ever wrote.) The alpha launch is planned for summer 2012. He recently published a paper with more details about ProofPeer.

On the subject of types vs. sets as a foundation I recall a funny cartoon that I found on a LtU thread related to this.

Back in 2008 Freek Wiedijk wrote a nice article on “Formal Proof—Getting Started”. Here is my favorite part of it:

In mathematics there have been three main revolutions:

• The introduction of proof by the Greeks in the fourth century BC, culminating in Euclid’s Elements.
• The introduction of rigor in mathematics in the nineteenth century. During this time the nonrigorous calculus was made rigorous by Cauchy and others. This time also saw the development of mathematical logic by Frege and the development of set theory by Cantor.
• The introduction of formal mathematics in the late twentieth and early twenty-first centuries.

Frank Quinne’s article “A Revolution in Mathematics? What Really Happened a Century Ago and Why It Matters Today” in  the January issue of Notices of the AMS is devoted to the second revolution. Here is a quote:

As the transition progressed, the arguments became more heated but more confined. At the beginning traditionalists were deeply offended but not threatened. But because modern methods lack external checks, they depend heavily on fully reliable inputs. Older material was filtered to support this, and as the transition gained momentum some old theorems were reclassified as “unproved”, some methods became unacceptable for publication, and quite a few ways of looking at things were rejected as dangerously imprecise. Understandably, many eminent late nineteenth-century mathematicians were outraged by these reassessments.
Meanwhile, very high reliability has been achieved in mathematics without drawing attention or having significance attached to it. The axiomatic-definition approach also made mathematics more accessible. A century ago original research was possible only for the elite. Today it is accessible enough that publication is required for promotion at even modest institutions, and an original contribution can be required for a Ph.D.

It is striking for me how well this describes the situation with the third revolution. The analogy extends also to the sort of democratization of mathematics that machine verification makes possible.

Here, is the collection of neighborhoods of zero (sets whose interior contains the neutral element of the group), and for two sets we define as .

Also, I replaced jsMath with MathJax as the LaTeX rendering engine on the isarmathlib.org site. The results are very good, the math renders faster and it looks better. It forced me to do some Haskell programming again to modify the tool that parses Isar and generates HTML with LaTeX markup. I haven’t seen that code or programmed in Haskell for about two years, but with Leksah now in Ubuntu repositories it was rather easy: just modify the code in one place and keep fixing it until it builds. Once it built, it worked.

The tool will probably become obsolete after the next Isabelle release. There is a Google Summer of Code project that will allow generating nice HTML presentations of Isar theories from within Isabelle.

Another small piece of formal math that I added in this release is a chapter in the Topology_ZF_2 theory on the pasting lemma. The classical pasting lemma states that if we have two topological spaces, say and and we partition into two sets , both open (or both closed), and a function is continuous on both and , then is continuous. The version in IsarMathLib is bit different, stating that the collection of open sets forms a topology.
Surprisingly from this we can conclude that the empty set (which in ZF is the same as zero of natural numbers) is continuous. Here is how it happens: since the collection forms a topology, belongs to it, i.e. is continuous. But is in fact and we get that zero is continuous. Ha Ha.
I would like to emphasize that I do not consider facts like this as demonstrating that ZF set theory is not a suitable foundation for formalizing mathematics (as some people interpret). It is just fun and games that formal math allows and I am sure other foundations also have their unintuitive corner cases.