The release happened actually more than a week ago, but it is only now that I got around to write about it.

The release brought very little of new formalized mathematics. Most of the effort went into getting the TiddlyWiki rendering work with more  IsarMathLib theories. This requires improving the Isar parser and modifying the theories  to conform to the Isar dialect that the parses assumes. As I modify the theories the Tiddly Formal Math site content diverges from the last released proof document and this release fixes that. The only significant change was the addition of a small tutorial on reading Isar formal proofs in the new Introduction.thy theory.

The IsarMathLib’s TiddlyWiki rendering got some praise on the Mizar mailing list recently.

I have posted a TiddlyWiki rendering of two IsarMathLib theories at tiddlyspot. The theories are Finite_ZF about the finite powerset and Topology_ZF about basic general topology. The rendering looks as I expected with great display of mathematical symbols and structured proofs with subproofs expanded on demand. The only problem is the indentation. I don’t know of a good method of controlling indentation in TiddlyWiki. There is a “{{indent{ ” construct, but this indents only one line instead of a block of text and does not mix well with the sliders. The “===” markup that marks the end of the slider is not noticed by TiddlyWiki when inside an indented line. In addition, indentation achieved this way is too wide - some twelve characters instead of perhaps three that I need for to see something like

   {

      fix 

      fix 

      assume A5: ,   

      with A1 A3 have 

         using apply_funtype

      with A2 A5 I have 

         using fix_var_val

   }

There is an old discussion on Gower’s Weblog where Gowers says

“Terry’s discussion of skeleton proofs is closely related to a fantasy I have had for a long time, which could I think become a reality. It’s to present mathematics in such a way that no step in any proof, no definition, nothing at all, is “magic”.”

Indeed, this can easily become a reality with the NestedSliderPlugin for TiddlyWiki. The reader could choose to see a short high level proof with the main points only, or expand the proofs of the facts that are unclear and see a very long and very detailed proof. Floating sliders can provide the statements of referenced theorems. This works very well to reduce verbosity of formally verifiable proofs as on the Tiddly Formal Math site, but would work for informal math too.

I have moved with my family from California to Massachusetts. I got an idea of taking a train. I don’t like to fly and the California Zephyr train goes through the most beautiful parts of this country. It has a “sightseer” car with big windows for watching the view. I thought it would be a four days vacation on train, fun for the kids and for us. I was wrong.
We departed from Emeryville, CA on time. The first problem showed up after about two hours, between Sacramento and Truckee. Someone had tried to drive a bulldozer over a railway bridge and got stuck there. We waited for Union Pacific to clear the mess for 15 hours.
It was actually not so bad for us. We were in a sleeper car. The situation of the people in the coach cars was much worse. Some were traveling with small kids, completely unprepared for longer travel. Some missed their wedding, others the Super bowl (I am not sure what that is but it seems to be very important for people here).
Since there were news reporters traveling on the train, Amtrak got bad publicity on this. This resulted in an Amtrak manager showing up on the train before we arrived to Chicago. He personally apologized for the 31 hours delay, which he assured us was very unusual for Amtrak. He promised that we would be put in a hotel in Chicago and our tickets would be rebooked for the same train departing two days later. It all looked good. We had a day of rest in Chicago which we used to visit the Field Museum.
However, when we showed up at the Chicago station to board the train it turned out that the rebooking part of the Amtrak’s manager promises was not quite true. The ticket counter attendant told us that he does not have space in the sleeper. The customer service representative (very unpleasant) told us that our only option was to take the coach seats. Traveling overnight in the coach seats with three small kids was out of the question. I would prefer to fly from Chicago to Boston. The problem was, Chicago airport was practically closed due to weather and most flights were canceled. Fortunately the ticket counter attendant was a bit more creative in exploring possibilities and suggested that we can take a different route to Boston through Washington, DC. So we boarded a train to Washington.
After traveling about 50 minutes the bad luck struck again. There was a flash flood warning and the train slowed down to 15 miles per hour. We traveled like that through the entire state of Indiana.
The next day my daughter had her 8th birthday. Instead of the new home she spent it on a train.
Since the new estimated time of arrival to Washington was 1 a. m. we were “detrained” in Pittsburg and bused to Harrisburg where we took a train to Philadelphia. We arrived there about 8 p. m. After spending four hours at the magnificent Philadelphia station we took a train to Boston where we arrived on time at 7:50 a. m., about 60 hours later than the original Amtrak schedule.

Conclusions

Traveling on Amtrak for more than one night is a bad idea, especially if you want to travel with kids. Even in a sleeper car it is very tiring. The tracks are sometimes uneven and when the train travels at 80 mph the noise and vibrations make it quite difficult to sleep. You can not open a window on an Amtrak train. The air inside the cars is as dry as on an airplane. The food is tasty and abundant, but it is mostly standard American cuisine, you know, burgers and the like. There are no fruits except bananas that come with the continental breakfast. You are bound to gain weight and the gain is proportional to the time of travel. The showers in the bedrooms are too small to be usable. Taking the family bedroom is a better deal. I didn’t take it (took a standard bedroom and a roomette) because it did not have a bathroom with a shower. There is a comfortable shower next to the (only) family bedroom in the car which was the one we used anyway. And of course the schedule is a joke. Don’t travel if you have any time commitment. Be prepared that you may be stuck on the train for seventeen hours when you expected a two hours trip. This is much better on the east coast which is the “Amtrak territory”, according to one of the car attendants. This means that Amtrak owns the tracks. In other parts of the country Amtrak trains have the lowest priority and have to wait for freight trains.

Aarne Ranta on Formal Mathematics in Informal Language

This talk considers generating readable prezentations of formalized mathematics as a special case of parsing and generating natural language statements. It looks like the idea is to translate at least formal definitions and statements, and perhaps also proofs, into the GF language, then generate natural language(s) reprezentation from that.

The talk is more about computer-supported linguistics than mathematics so I don’t want to pretend I understand what is on the slides. Some interesting comments from the author can be found on his blog.

Cezary Kaliszyk on teaching logic using web interface for COQ

The slides are actually about a bit more than the title says. Cezary’s web interface to provers is the closest thing to the formalized math wiki that exists. It is quite generic and besides COQ it supports (at least) Isabelle back end. It even supports Isabelle/ZF so it already can be used for learning the prover without having to install it. I was not able to verify IsarMathLib theories though as the interface seems to have problems with mixing formal text, informal text and comments.

Christoph Lüth on PGIP

PGIP is a protocol for communication beween a proof assistant front end (editor) and a theorem prover. It seems that in practice at the moment it is used only by Proof General front-end to talk to Isabelle prover. I am using XEmacs based version of Proof General and I am quite satisfied with it. Through some wizard-level hackery the PG developers managed to coerce Emacs to display subscripts and some mathematical symbols, so it is almost WYSIWYG.

One of the slides from the talk is a screenshot of the new generation of Proof General, based on Eclipse. Eclipse is more known as a platform for software development tools rather than document creation tools, so I was afraid it would be a step back as far as formalized mathematics is concerned. But from the slide I can see that there will be some mathematical symbols support. Hopefully all those gadgets around the main editing frame can be turned off and the new PG will be at least as good as the old one.

I am curious what was the rationale for selecting Eclipse for the Proof General basis, instead of for example creating a GNU TeXmacs PGIP plugin. TeXmacs has excellent support for mathematical typesetting and is specially designed to be a front end to other programs, currently mostly Computer Algebra Systems.

Herman Geuvers on Wiki for formalized mathematics

I think this was the most important talk on the conference. Herman Geuvers discussed the plan for getting the EU taxpayers money to finance the development of a formalized mathematics Wiki.

I really want this project to succeed. Writing formalized mathematics is fun, but I imagine doing it in a collaborative Wikipedia-like environment would be much more fun.

In my opinion one of the main obstacles for such Wiki is that most theorem provers don’t support generating readable presentations of formalized text.

“Readable” means different things to different people. For some people “readable” means “looks like Lisp”. Here by “readable proof” I mean one that uses standard mathematical notation and terminology and anyone with some mathematical education is able to follow it without having to learn a new language with words like “constdefs” and “assms”.
The author seems to realize the problem, but the solution that is suggested in the slides is wrong. The idea for the solution is that the formalized math Wiki would contain lots of nicely typeset informal math content so that it can compete with Wikipedia or MathWorld. Then, as soon as an unsuspecting visitor gets lured to the site she would be flashed with a formal proof that looks like this:

intros k l H; induction H as [|l H].

intros; absurd (S k <= k); auto with arith.

destruct H; auto with arith.

(this is taken from Freek Wiedijk’s slides).

I am not against informal text. In fact, most of the volume of IsarMathLib proof document is informal. Just like a standard math paper needs more than just definitions, theorems and proofs, formalized math text needs some informal text to dilute content, explain motivation, mention other people’s work or simply provide keywords to make searching easier. However, this should not be the main ingredient. The approach that reduces formalized text to an optional comment on the informal content misses the point. If a prover does not feature generating readable presentations, it is simply not suitable for formalized math Wiki.

I certainly hope that I am misunderstanding Geuvers’ vision. My opinion is mostly based on a (mockup?) slide with screenshot of a prototype of such Wiki that is included in the talk, so this is very little information. I really wish this project to be a success.

To be continued …

To my delight I have found that the all presentations from the TYPES topical workshop “Math Wiki” that took place in Edinburg, Oct 31 - Nov 1, 2007 have been posted on the web. This is a lot of interesting reading on formalized mathematics. I will discuss some of my impressions here.

Klaus Grue on LogiWeb

This is a description of LogiWeb - a system for … I don’t really know. My first impression was that it is kind of like Hilbert II - another project building infrastructure for formalized mathematics that asymptotically approaches the difficult part in its lifetime - actually formalizing the math and creating libraries. However after looking at the objectives (fundationally agnostic) and an example proof (very low level with no prover support) I started to think that this is how Metamath would look like if Norman Megill had spent all these years writing software for formalizing math instead of creating formalized math.

As I was reading the presentation trying to understand what LogiWeb is I had more and more problems in putting some bounds on what LogiWeb can do. It has a built-in version control (or rather package management) that allows to maintain consistency of changing interdependent knowledge representations (very good idea). It can output (”render”) files in .html, .xml, .lisp, .exe formats and in fact any other format. It can create “Logiweb machines” that are Turing-complete and support input/output capabilities, interrupt handling, distinction between supervisor and user-mode and non-preemptive scheduling. Logiweb machines can run real-time, safety critical software. As for formalized mathematics, LogiWeb can support Peano Arithmetic as well as mainstream theories like FOL, PA, ZFC, NGB and so on. That’s all great but I have a feeling that Klaus Grue uses the word “can” in a rather metaphoric way. He should really be saying “potentially can” to be more clear.

To me software for doing formalized mathematics becomes interesting when:

1. it supports ZF set theory or something similar (really, now, not potentially),

2. some work has been done on formalizing a bit more than foundations so that I can evaluate how readable the proofs can be made and how easy they are to write.

It looks like LogiWeb is not at this point yet.

Adam Naumowicz on Mizar

Mizar is still the best tool for a mathematician to do formalized mathematics. Online interface? Mizar has had it for a while now.

Too bad Mizar is not free.

Carsten Schürmann on Logosphere

Logosphere is a formal digital library project developed (mostly) by Department of Computer Science of Yale University.

Logosphere’s approach reminds me a bit of Sage - a very succesful mathematical software project which is based on integrating existing tools rather than inventing new ones, as they call it “Building the Car Instead of Reinventing the Wheel”. Similarly Logosphere tries to serve as a common platform for translation between different theorem provers.

Schürmann prezentation contains a very informative picture on different logical frameworks and provers that support them. This brings up the question - which foundation is the best for a community based formalized mathematics wiki project? In other words, which foundation has a best chance to attract a significant number of contributors?

I think there is a big difference beween the view on foundations of mathematics among mathematicians and computer scientists. If someone made a survey at a math department asking faculty a question on what mathematical foundation their work is based on, I am sure most would answer “ZFC”. The majority of the remaining ones would say that they don’t care because it does not play any role in their work or say something generic, like “logic and set theory”, just because they are not even aware there is something else than ZFC. The majority of the remaining ones would declare that they work in category theory or maybe something more exotic like that they are constructivists.

Over at the computing science department the situation would be quite different. ZFC is not good for formal software verification or modeling computation. As a result there is much greater variety of logics and type theories that count as foundations for computer scientiststs. Theorem provers are typically created at computing science departments. No wonder that so few provers (Isabelle and Mizar) support ZFC.

Another reason support for ZFC is rare is that funding for formalized mathematics projects is often obtained by promising something like “the production of mathematically proved programs” (Cornell, NuPrl, grant from the Office of Naval Research). Once your stated goal is formally verified software, ZFC is gone from the picture, together with a chance for a larger participation of people with standard mathematical education .

I am a mathematician by training and I have tried to use Isabelle/HOL. It was weird and I felt like I was writing software rather than mathematics. I could do it, but it was not fun. Isabelle/ZF, on the other hand was easy and natural. That’s why IsarMathLib is a library for Isabelle/ZF, not Isabelle/HOL.

To be continued…

I have released version 1.6.2 of IsarMathLib . This is the first version that has been verified with Isabelle 2007. I also added a new thery file about folds in ZF set theory, presented before on this blog, and rewrote the theory file about semigroups.

Freek Wiedijk has posted the slides from his talk “How to build a library of formalized mathematics” on the MathWiki Workshop in University of Edinburgh that took place in October. The slides present Freek’s view on the main reasons why there is no large scale effort to create a good and comprehensive library of formal mathematics. What I find striking is no mention of Metamath among “interesting” or even “not in the top five” category. I understand that one can not mention every project (although, are there that many that have been active for more than ten years?), but Metamath is the only formalized mathematics project that managed to build community and attract contributors working without any expectation of reward. There are other formalized mathematics projects that people contribute to, but the contributions are either work of graduate students getting their degrees this way or faculty doing research for which they get their salaries. Freek mentions Linux and Wikipedia as succesfull projects based on “benevolent dictatorship”, but not the only formalized mathematics project in this category.

Unfortunately the slides are rather sketchy and only illustrate the main points, so it is hard to guess what was actually said. I would be happy to find out what was discussed under “formalization for communication of mathematics” and “looks do matter”. I think the most important feature needed for attracting contributors is the ability to produce readable presentations that attract readers.

My impression that the new Isabelle 2007 does not break anything related to ZF was a bit premature. It turns out that the interpretation of locales has changed. There is a locale (context) in IsarMathLib called MMIsar0 that is used for Metamath to Isabelle/ZF translation. This locale has twenty five assumptions corresponding to Metamath’s axioms for complex numbers. The MMIsar_valid theorem in Metamath_interface.thy shows that if we take a model of real numbers (i.e. a completely ordered field) and contruct the complex numbers from it in the standard way, then all Metamath axioms about complex numbers are satisfied. The problem is that those assumptions in MMIsar0 are interpreted by Isabelle 2007 not as a flat conjunction, but are grouped with parentheses into a complicated structure nested up to four levels deep in some places. It is not a show stopper, but it will take me some time to reflect this nesting structure in the proof.

This is a symptom of a deeper, architectural problem. When verifying a proof written in Isar Isabelle searches for a low-level proof and once it finds one it considers the Isar proof verified, so it discards the low-level proof. This causes problems every time the proof searching algorithm is changed - that is with every new Isabelle release. Some proofs that were succesfully verified before don’t check any more. The only solution to this is to design a system so that the low-level proof is not discarded. Once the low-level proof corresponding to high-level source constructs is found, it can serve as the basis of verification and does not need to be generated again. I think while Isar is great for a high-level proof language, something like Metamath would be great as the underlying low-level language.

I have finally finished the tool for converting Isabelle verified IsarMathLib source to a blog entry. Writing a parser with Haskell’s Parsec library was a pleasure as usual. The post below was generated from the Fold_ZF.thy theory file that will be included in the next (1.6.2) release of IsarMathLib.

Having a parser opens the possibility of exporting the IsarMathLib source to different formats. I have been thinking what my next target should be and decided it should be TiddlyWiki.

Why TiddlyWiki?

There are two most important features that a good presentation of formalized mathematics should have.

1. Mathematical notation including mathematical symbols.

You can not effectively communicate mathematics without mathematical symbols. Most theorem provers designers seem not to understand this. It is a mystery for me why the designers of programming languages are stuck at the set of symbols that were present on those typewriters that people used to talk to IBM mainframes in the sixties. It obviously wastes the bandwith of human visual cognition channel that can recognize thousands of symbols easily and fast. Fortunately Isabelle is an exception to this - it allows to define any number of custom symbols and specify how they should be typeset in the proof document. As for TiddlyWiki the jsMath plugin allows beautiful display of LaTeX math notation, much better that what you can see in this blog.

2. Ways to deal with excessive verbosity of formalized math

Formalized proofs contain much more details than informal ones. It is good in some way that a machine will not accept proofs written in style “using methods similar to those in [1] modified in a way analogous to [2] we can show that …” . On the other hand having too much detail can make it difficult to see the main idea and the big picture of a proof. Isabelle’s Isar language allows to write structured proofs where the proofs of the main points can be can be separated in the whole proof text so they can be skipped by the reader if the fact is obvious to him/her. TiddlyWiki’s NestedSlidersPlugin would allow to expand such sub-proofs only on demand, so that they don’t obstruct the flow of the main proof.

Another aspect of verbosity of formal proofs is that they typically reference many more other theorems than a typical informal proof. It is sometimes difficult to see which of the referenced theorems are essential to understanding of the proof and which ones are only the glue logic. Isabelle allows to add some theorems to the simplifier where they effectively become the background knowledge that is not necessary to reference directly in proofs. The NestedSlidersPlugin does something even better - it can make the theorem reference clickable, so that the reader can easily examine what the referenced theorem is saying in a window floating over the main text.

And now some formalized mathematics about folding in ZF set theory.

theory Fold_ZF imports InductiveSeq_ZF

begin

Suppose we have a binary operation written multiplicatively as . In informal mathematics we can take a sequence of elements of and consider the product . To do the same thing in formalized mathematics we have to define precisely what is meant by that ““. The definitition we want to use is based on the notion of sequence defined by induction discussed in InductiveSeq_ZF. We don’t really want to derive the terminology for this from the word “product” as that would tie it conceptually to the multiplicative notation. This would be awkward when we want to reuse the same notions to talk about sums like .
In functional programming there is something called “fold”. Namely for a function , initial point and list the expression fold(f, a, [b,c,d]) is defined to be f(f(f(a,b),c),d) (in Haskell something like this is called foldl). If we write in multiplicative notation we get , so this is exactly what we need. The notion of folds in functional programming is actually much more general that what we need here (not that I know anything about that). In this theory file we just make a slight generalization and talk about folding a list with a binary operation with not necessarily the same as .

Folding in ZF

Suppose we have a binary operation . Then every defines a transformation of defined by . In IsarMathLib such transformation is called as Fix2ndVar(f,y). Using this notion, given a function and a sequence of elements of we can get a sequence of transformations of . This is defined in Seq2TransSeq below. Then we use that sequence of tranformations to define the sequence of partial folds (called FoldSeq) by means of InductiveSeqVarFN (defined in InductiveSeq_ZF theory) which implements the inductive sequence determined by a starting point and a sequence of transformations. Finally, we define the fold of a sequence as the last element of the sequence of the partial folds.

Definition that specifies how to convert a sequence of elements of into a sequence of transformations of , given a binary operation .

definition

Definition of a sequence of partial folds.

definition

Definition of a fold.

definition

If is a set with a binary operation then Seq2TransSeqN(f,a) converts a sequence of elements of into the sequence of corresponding transformations of .

lemma seq2trans_seq_props:
   assumes A1:   and
   A2:   and
   A3:   and A4: 
   shows   and
   
proof -
   from  have D: 
      using func1_1_L1
   with A2 A3 A4 show 
      using apply_funtype fix_2nd_var_fun ZF_fun_from_total Seq2TrSeq_def
   with A4 D have I: 
      using Seq2TrSeq_def ZF_fun_from_tot_val0
   {
      fix 
      fix 
      assume A5: ,   
      with A1 A3 have 
         using apply_funtype
      with A2 A5 I have 
         using fix_var_val
   }
   thus 
qed

Basic properties of the sequence of partial folds of a sequence .

theorem fold_seq_props:
   assumes A1:   and
   A2:   and
   A3:   and A4:   and
   A5:   and A6: 
   shows ,     and
   
proof -
   let 
   from A1 A3 have D: 
      using func1_1_L1
   from   have I: 
      using fstdomdef
   with A1 A2 A3 A4 A6 D show II:   and 
      using seq2trans_seq_props FoldSeq_def fin_indseq_var_f_props
   from A1 A2 A3 A4 A6 I D have 
      using seq2trans_seq_props FoldSeq_def fin_indseq_var_f_props
   moreover    {
      fix 
      assume A5: 
      hence 
      with A1 A2 A3 II A5 have 
         using apply_funtype seq2trans_seq_props
   }
   ultimately show 
qed

A consistency condition: if we make the list shorter, then we get a shorter sequence of partial folds with the same values as in the original sequence. This can be proven as a special case of fin_indseq_var_f_restrict but a proof using fold_seq_props and induction turns out to be shorter.

lemma foldseq_restrict:
   assumes ,     and
   ,   ,
   ,     and
   ,
   ,   ,   
   shows 
proof -
   let 
   let 
   from assms have ,   ,     and
   
      using fold_seq_props
   then show 
      by (rule fin_nat_ind)
qed

A special case of foldseq_restrict when the longer sequence is created from the shorter one by appending one element.

corollary fold_seq_append:
   assumes ,
   ,     and
   ,   ,   
   shows 
proof -
   let 
   from assms have ,   
      using append_props
   with assms show 
      using foldseq_restrict
qed

What we really will be using is the notion of the fold of a sequence, which we define as the last element of (inductively defined) sequence of partial folds. The next theorem lists some properties of the product of the fold operation.

theorem fold_props:
   assumes A1:   and
   A2: ,
   ,   ,   
   shows   and 
proof -
   from assms have 
      using fold_seq_props
   with A1 show   and 
      using last_seq_elem apply_funtype Fold_def
qed

The next theorem tells us what happens to the fold of a sequence when we add one more element to it.

theorem fold_append:
   assumes A1:   and
   A2:   and
   A3:   and
   A4:   and A5: 
   shows   and
   
proof -
   let 
   let 
   from A5 have I: 
   with assms show thesis1: 
      using fold_seq_append fold_props
   from assms I have II: ,
   ,   ,
   ,   ,   
      using append_props
   then have 
      by (rule fold_seq_props)
   with A3 A5 thesis1 have 
      using append_props
   moreover
   from II have 
      by (rule fold_seq_props)
   then have 
      using last_seq_elem Fold_def
   ultimately show 
qed

end

The formal part of this blog post has been generated from IsarMathLib’s Fold_ZF.thy theory file, see the relevant pages of the IsarMathLib proof document.