Hilbert II

Table of Contents

Overview

This is an unstable development release of Hilbert II. In the tradition of Hilbert's program the project creates a formal correct (checkable by a proof verifier) but readable (like an ordinary LaTeX textbook) mathematical knowledge base which is freely accessible within the internet. The mathematical axioms, definitions and propositions are combined to so called QEDEQ modules. Such a module could be seen as a mathematical textbook which includes formal correct proofs. The project started with logic and set theory.

This release contains a program suite that can produce LaTeX and UTF-8 files out of QEDEQ XML files. The QEDEQ files can be checked for syntactic correctness. Simple formal proofs can also be validated. For set theory we provide some small finite models. Checks for model validity are also available. The following files were mostly generated out of QEDEQ modules and contain more information. Some files are also available in German and not in our terribly, awfully bad English...

A convenient way to start this application is via Java Web Start. Just click on: START. There should be a splash screen for Java Web Start, asking you to trust the signature. Although it will be not recommended you must trust the signature of Hilbert II to start the application. If you already started an older program version via Web Start you should remove the files in the config directory. In this case you must also empty the local buffer directory by selecting File / Clear Buffer in the menu.

Project Goals

The goal of Hilbert II is decentralized access to verified and readable mathematical knowledge. The knowledge base contains mathematical texts in different languages and detail levels, axioms, definitions, propositions and their proofs. Beside common non formal proofs the system includes formal proofs that were verified by a proof checker.

The mathematical axioms, definitions and propositions are combined to so-called QEDEQ modules. Such a module could be seen as a mathematical textbook. At least all proposition formulas are written in a formal language and each proposition can also have a formal correct proof. The proposition is verified iff it has a formal proof and all required propositions are also verified.

Hilbert II will provide a program suite that enables a mathematician to put data into that knowledge base and retrieve various documents and analyze results out of the system. This includes the generation of LaTeX files that look like a common mathematical textbook and the answer to questions like "assumes this theorem the axiom of choice?" for verified propositions. As it's name already suggests, this project is in the tradition of Hilbert's program.

Because this system is not centrally administered and references to any location in the internet are possible, a world wide mathematical knowledge base could be build. Any proof of a theorem in this "mathematical web" could be drilled down to the very elementary rules and axioms. Think of an incredible number of mathematical textbooks with hyperlinks and each of its proofs could be verified by Hilbert II. For each theorem the dependency of other theorems, definitions and axioms could be easily derived.

See also under QEDEQ basic concept for more project details. This document was generated out of the following XML file: qedeq_basic_concept.xml.

Mathematics

The mathematical knowledge of this project is organized in so called QEDEQ modules. Such a module can be read and edited with a simple text editor. It could contain references to other QEDEQ modules which lay anywhere in the world wide web. A QEDEQ module is structured like a mathematical text book. It contains chapters which are composed of paragraphs each with an axiom, abbreviation, definition or proposition. Every paragraph has a label and could be referenced by that label. Essential formal element of a paragraph are formulas. The formulas are written in a first order predicate calculus, also the proofs are in this language. Therefore a proof verifier can check the formulas and their proofs for formal correctness. We can create linked mathematical text books. And with the extended analytic possibilities of the formal language we can easily do for example a dependency analysis.

In addition to the basic rules also other derived rules, so called meta rules, could be used. A proof that uses meta rules could be automatically transformed into a proof which only uses the basis rules. Some other language extensions, for example defined predicate constants, are established for shorter writing and convenient argumentation. These extensions can also be automatically removed and transformed into the original system.
We are aware of the fact that this transformation is not in each case practically realizable. For example it is not possible to write down the natural number 1000000000000000 completely in set notation: {{}, {{}}, {{}, {{}}}, {{}, {{}}, {{}, {{}}}}, ...}.

The QEDEQ XML files have a formal structure that is defined here or here. The logical language is described in qedeq_logic_language_en.pdf (in development).

In Hilbert II a formal language is used which enables us to describe most domains of mathematics. It is a first order predicate calculus based on the text Elements of Mathematical Logic from P. S. Novikov. The logical axioms and basic rules originate from the book Principles of Mathematical Logic (Grundzüge der theoretischen Logik) (1928) by D. Hilbert and W. Ackermann. They are presented in qedeq_logic_v1.pdf. The propositions are not complete and proofs are missing, but the mathematical orientation becomes clear.

Recently we changed the logical structure along the lines of Vilnis Detlovs and Karlis Podnieks Introduction to Mathematical Logic to have a fully formalized presentation. Please take a look at qedeq_formal_logic_v1.pdf to see the current state. This document contains all axioms and rules for predicate calculus. It also has some propositions with formal proofs (checkable by our proof checker).

Beside logical ones the only axioms in Hilbert II are those of axiomatic set theory. As usual for mathematics the axioms of all other theories could be expressed as simple predicate constant definitions. With common mathematical practice in mind, the set theory used here is not ZFC but Morse-Kelley (an impredicative Neumann-Bernays-Gödel extension). Our mathematical basis text is E. J. Lemmon's wonderful Introduction to Axiomatic Set Theory. Along these lines, we wrote a script about axiomatic set theory. This script is also available in German. It contains already some non formal proofs. In the XML source all formulas of axioms and propositions are already written in the formal language. The main goal is the completion through the addition of formal proofs. New proof methods are necessary to accomplish this.

Installing, Starting and Working

Precondition is a Java Runtime Environment, at least version 1.4. From Download Java 2 Platform you could get the Java Runtime Environment J2SE v 1.4.2 JRE. To work with the created LaTeX documents you need an appropriate LaTeX environment.

You can start the application by the script qedeq_se.bat or qedeq_se.sh in the main directory. If you connect to the internet via a proxy server you should start the preferences dialog via the menu Tools / Preferences. There you can enter the appropriate proxy parameters.

To start the application more manually call via java:

  org.qedeq.gui.se.main.QedeqMainFrame

The classpath must include the files in the lib directory..

You also can start the applicaton via Java Web Start. Just click on: START.

Sample XML files can be found in the sample directory. The main structure of an QEDEQ XML file looks like the LaTeX book format. There is a special kind of subsections called node that contain an axiom, definition or proposition. Each node is labeled and could be referenced by that label. Here is the XSD and here it's documentation. The root element is called QEDEQ.

So what can we do? You can load existing QEDEQ modules from the local file system or via http. Files loaded from web are stored in a local buffer directory. Even after successfully buffering a QEDEQ module loading it might fail due to XML validation or elementary application errors. In such a case the tree icon changes its color to red. A successfully loaded module looks dark grey. To get some modules we just select File / Load all from QEDEQ.org. Depending from your internet connection you will see new modules appearing in the tree at the left side. They will successive change their color from baby pink into dark grey. Some modules even get a little bit of red color. The log panel lists all module states changes.

By selecting a red module at the tree the state panel will show more details about the selected module. If you select the error module qedeq_error_sample_00 and activate the pane labeled Errors you will see an entry like cvc-complex-type.2.4.a: Invalid content was found starting with element 'XOR'. One of '{"":FORMULATYPE}' is expected. This list entry describes am XML parsing error that occurs in line 36. If you click on this entry the XML source will open at the error location in the QEDEQ panel. The error location is marked and we see the usage of the unknown element 'XOR'.

If you look at qedeq_error_sample_12 you can see an application error. This module has two Nodes that have the same id. This is a violation of the uniqueness of nodes and leads to an loading error. By the way, the state of the module is loading into memory failed the other red modules have the state loading from local buffer failed.

Now we have various plugins to work on a loaded module. Firstly you can select a module and choose Show module as UTF-8 text in the context menu. This plugin transforms a QEDEQ module into an UTF-8 text and displays the result in an extra window. We try that on module qedeq_sample3 and see same axioms, propositions and their proofs. The layout and format of the displayed text is not satisfying but you get a visual impression of the QEDEQ module.

Now we test the generation of UTF-8 text files by selecting the appropriate context menu entry on qedeq_sample2. We notice that three modules change their color to green. First qedeq_logic_v1 second qedeq_set_theory_v1 and last qedeq_sample2. The green color is a signal for the state well formed. This means all imported modules are well formed too and that all formulas passed the syntax checker. This check was initiated by the UTF-8 text plugin because the plugin has to know the LaTeX representation of every imported operator. If loading an imported module fails then the plugin tries to use backup definitions for unknown operators. We see the location of the generated UTF-8 text files in the log pane and can open such a file within a web browser. (Perhaps you must change the encoding to UTF-8.)

If we generate UTF-8 files for qedeq_sample1 or qedeq_logic_language the modules turns yellow and we get some warnings because the LaTeX texts contain not supported constructs. To remove plugin errors and warnings you can select Remove Plugin Results in the context menu for the appropiate module.

Now we come to the important features. We take qedeq_sample3 and start Check Well-Formdness. Firstly all imported modules are checked for being well formed. Then the rest of the module is sequentially analyzed. Formulas are checked for beeing well formed and that their operators are all defined. There should be no problems with qedeq_sample3 and the module status color should change to green. Now we want to know if the module is fully correct - that is all propostions have correct formal proofs. So we start the Check Proof plugin and the state changes to well formed; Check Proofs successful. All other QEDEQ modules (beside qedeq_formal_logic_v1) with propositions will get errors. We test that with qedeq_sample1. We see that qedeq_logic_v1 and qedeq_sample1 both change their colors to red. qedeq_logic_v1 has still no formal proofs and neither has qedeq_sample1.

To get an impression of the logical basis for this project we check the proofs of qedeq_formal_logic_v1. It contains the logical axioms and rules of inference for our predicate calculus and some basic propositions with formal proofs. It even uses the derived rule conditional proof. Just look at the UTF-8 text to get an impression of the logical roots. For further information you should visit Introduction to Mathematical Logic by V. Detlovs and K. Podnieks.

We now try proof checking with qedeq_sample4 and get also errors for missing formal proofs. But now we try the new (experimental!) plugin Find Proofs. If you start it directly it will search for much to long. You have to restrict the substitution usage. Just go to the plugin preferences dialog and the Find Proofs tab. There you should change the weight values for the operators from implication to equivalence from 1 to 0. Now after quite a while (ten minutes on an an Intel Celeron with 2 GHz) the plugin can find the missing proofs. It works only for propositional proofs and uses brute-force. If we execute Check Proof now the color changes to green. The plugin changes only the buffered file so you loose these findings after executing Clear Buffer. By the way: the blue color signals that all neccessary imports were done.

During a plugin execution (proof finding is a good example) one could check the execution status by selecting the menu entry Plugins / Threads. The new window shows all plugin processes that were executed. If you select a running process you can see the current element the plugin works on. The proof finder plugin shows you even the last generated proof line.

We still provide no further tools to create new QEDEQ modules. You still have to copy an existing QEDEQ file and modify its content. A file modification that takes place after the module is already loaded is not recognized. You must Remove the module and then Load local file. If you modified an already buffered file you must do even more. The application takes the local buffered file when reloading such a file. The buffer location can be found under Tools / Preferences. You have to clear the buffer via File / Clear Buffer.

For propositional calculus we included a small tool that helped us to integrate new formal proofs into our system. You can start it via the menu entry Tools / Proof Text to QEDEQ. You can add a proof in text form at the left upper window. Just click Transform / Proof Text to QEDEQ in the menu when you are ready. At the bottom you see the generated XML snippet for the proposition including the formal proof. At the upper right window you see the generated UTF-8 text. Just compare it to the original at the left side if you want to be shure everthing got parsed correctly. There is still no syntax description for the format. You have to look at the sample and you might want to change the file "config/proofTextMathOperators.xml" according to your needs.

Modules without errors are reloaded automatically when the application is restarted. This behavior can be changed in the Tools / Preferences menu.

This release includes the source code and the JUnit test classes. The code coverage results of these tests where produced by clover .

Release Contents

Further Installation

Beside the steps mentioned in Overview you should install a correction for the buggy LaTeX package longtable. One possibility is this patch from Chung-chieh Shan. It was used to produce the provided PDF files.

Licenses

The QEDEQ XML files stand under the GNU Free Documentation License (GFDL), the software of this project under the GNU General Public License (GPL).

For XML parsing the apache parser is used which falls under the apache license. This license applies also to the class com.sun.syndication.io.XmlReader which was taken on 2008-03-06 from project Rome (see https://rome.dev.java.net/../XmlReader.java). The GUI uses the tango theme that is under the Creative Commons Attribution Share-Alike license. There are also some icons of the Open Icon Library included. These icons stand under different licenses.

Hilbert II uses JGoodies Looks and JGoodies Forms, distributed by JGoodies under the terms of the BSD License see looks license and forms license for details. Also included are three additional classes (SimpleInternalFrame, Factory and UIFSplitPane) by Karsten Lentzsch, which are distributed under these terms.

We also used some great work of Santhosh Kumar. This code is distributed under the GNU Lesser General Public License.

Future Development

For the current source code you could browse the subversion tree.

Here are descriptions of the next minor releases. Subversions are not listed. All these releases are characterised as "unstable" and are only of interest for developers.