For several years, this author (Nathan Carter) has used the textbook forallX by P.D. Magnus in his introduction to logic course for honors students at Bentley University (MA305H). It’s clear, it’s free, and it covers a lot of interesting material. It only accounts for about two-thirds of the course, and the other third is various uses of logic.

Since *Lurch* became mature enough to handle the course content, I wanted a book that integrated *Lurch* lessons through the course, for ease of use by my students and ease of adoption by other professors.

Since Magnus’s text was free and open-source, I was permitted to take his work and adapt it to my setting. I did so in Summer 2013, and *forallX in Lurch* was born. I used the new text in my logic course in Fall 2013, and have posted it on the web under the same license as the original.

(The original text–without *Lurch–*is on Magnus’s website.)

This new text serves two main purposes.

- If you’re teaching a logic course and want to use
*Lurch,*adopting this text will save your students money and save you time integrating the software into the course, because that’s already done by the book. Corresponding .lurch file downloads are on the book website. - Know math but not
*Lurch?*Want to learn without figuring it all out on your own? Flip through the text, skip the math you already know, and just focus on the software lessons. They begin at the very beginning (installing*Lurch*and typing text) and end at the advanced (declaring variables and using them in proofs with quantifiers).

Enjoy! As always, feedback is welcome, especially on our email list.

]]>Every *Lurch *user benefits from bubbles; you can’t use *Lurch *without them. But this post covers a part of *Lurch *generally seen only by instructors, not students.

After installing *Lurch,* the blank document you see on first launch of the app is not really blank at all. It “depends on” a whole host of mathematical definitions, theorems, and rules of logic that are available for your use in that document. You can see this list if you go to the Meaning menu and choose “List all defined rules.” *Lurch* shows you a long list, the beginning of which is shown here.

These are just five of the over 100 rules *Lurch *knows. So why did I say, “There are no rules!?”

Because you don’t have to accept our rules! You can throw them all away and start from scratch if you like, or keep some and throw away others. Our team included many common rules of mathematics in *Lurch *our way, but you can rewrite them your way, or even invent a system of reasoning that has nothing to do with these rules.

We’ve had this design goal from the beginning. If you’re teaching a course on nonstandard logical systems, or the surreal numbers, or non-Euclidean geometries, you should be able to cast aside the normal rules and replace them with new ones. Let’s see how.

In part 1, we saw how bubbles communicate meaning to *Lurch.* Each has a certain role, and you can click its tag to change that role–including specifying that the role is to *define a new kind of rule.* This blog post won’t go into great in detail, but eager rule-makers can dive into the Advanced Users’ Guide (which is also in *Lurch*‘s built-in help).

I give one example, from a document that ships with *Lurch, *that defines rules for propositional logic.

Here the user creates an outer bubble of type “if-then rule,” and uses an inner bubble to specify that a portion of the inside represents an assumption. Similar inner bubbles will mark “contradiction” as a required premise and “W” as a conclusion. A property bubble (also mentioned in part 1) can give the rule a name, and that’s it! Just having the rule in your document lets *Lurch *knows it. You can cite it later in your document and *Lurch *will use it to check the corresponding step of work.

All the rules built into *Lurch *were created this way! Instructors can even put their rules into a separate document so that students can cite them without having to explicitly rewrite each rule in their assignments. There’s more to it than in this simple example, but that’s the essence.

It does! In fact, I’ll give you three good reasons to trust that it works.

First, *Lurch *has been tested in two semester-long courses, one in 2008 and one in 2013, and in both cases, only a few bugs were found, and they were fixed.

Second, the *Lurch *developers have an extensive test suite that they use to verify that the *Lurch *validation engine does what it’s supposed to do.

Third, the declaration and validation system is based partially on established mathematical research (thanks, Dan!), and comes with a theorem of its own that the design of our system accomplishes correct validation of users’ documents.

If this seems cool to you, get a copy of *Lurch *and dive into the Advanced Users’ Guide so you can make your own rules!

There are three answers, but this post only hits on two of them, because the third is large enough for its own post. (Hence this post is titled “part 1 of 2.”)

To judge your mathematical reasoning, *Lurch* needs to know more than a typical word processor–not just how your document should *look, *but what your document *means.*

(This is different than WYSIWYM, where the system needs to understand what you mean in terms of your document structure. *Lurch* needs to understand what your symbols mean *mathematically.* If you write *a*+*b*, a typesetting system does not care whether it’s adding integers or combining elements of a group, as long as it typesets it nicely. *Lurch* cares, or it can’t judge your work.)

The ability to store mathematical semantics in a word processing document has been built into *Lurch *since the beginning.

The green lights follow steps of work *Lurch* judged correct, red lights incorrect. (In this example, the red light is because the wrong reason was provided.) Yellow lights follow steps that are unjustified, but used later, a.k.a. hypotheses or “givens.”

The screenshot above may make you ask, “Surely the software is not reading actual English prose, and lifting meanings from it!” Indeed, natural language processing is a hard problem, and *Lurch *does’t do it. So how does it know which words to pay attention to?

The user indicates each meaningful phrase with a single click or keystroke. It’s as easy to mark something meaningful as it is to apply a format like **bold** or *italic.*

In the screenshot below, the user has highlighted a phrase containing mathematics, and the mouse pointer (not shown) is hovering over the red button entitled “Insert meaningful expression.”

The user clicks that button, and the document changes.

The red “bubble” around the phrase indicates that *Lurch* understands its mathematical meaning. (The “∀ quantification” means that the expression is universally quantified. Other expressions have other labels, such as “+ expression.”)

Like in Word’s equation editor, bubbles are only visible when the user’s cursor is in them. Thus the first screenshot in this post is not cluttered with bubbles, but they’re there.

This paradigm gives the author the ability to write as much exposition between steps of work as they like, even including nonsense (e.g., an example of what not to do), and *Lurch *will happily ignore it, until the next phrase the author marked as meaningful.

Marking which words are reasons is very similar; the user clicks the blue toolbar button to create a different kind of bubble, one that modifies a red bubble.

The arrow on the reason bubble points to the meaningful expression it modifies. (The red bubble is invisible because the cursor is in the blue one.)

So users can write documents however they like, with bubbles as a thin layer of decoration that tells *Lurch *the author’s intentions. But their writing style is unrestricted; they write proofs as they see fit. To prove it, I end with three screenshots of the same proof, done in three very different styles. *Lurch *has validated each step in each style; only the mathematics within the style matters to *Lurch.*

*Lurch should be as indistinguishable from the ordinary activities of mathematics as possible, except for the additional services it provides. That is, it should only add to your math experience, not change your math experience.*

This is our user interface guideline. People write math in their style, a notation they’ve learned, with exposition where they feel it’s helpful. This is true on chalkboard, paper, or LaTeX. So the Lurch user experience must be as similar to those activities as possible. Except, of course, that pencil and paper won’t tell you whether your proof is correct, but Lurch will.

When designing our user interface, if choice A seems *more *like typical mathematics than choice B, we choose A. There is always room for improvement in this area; we always have ideas that we haven’t yet built. Even so, what we have now is pretty natural.

But that’s for another post…for now, let’s see part 2 of the mission statement.

*Lurch should provide the software infrastructure the mathematical community needs for validating rigorous mathematics. That is, it should validate mathematical content created by you — a “spell-checker” for mathematical rigor.*

Admittedly, this could be clearer–there already *are *impressive pieces of software (e.g., Mizar) that validate rigorous mathematics. But proof checkers like Mizar are different from Lurch in these ways:

**They make you learn a specific language and rules.**(Lurch lets you define the rules–and eventually the language, but not yet.)**They automate some proof steps.**(Lurch expects you to do the work, and it checks it. Lurch doesn’t help you prove, but helps you*learn*to prove.)**Their user interface is for advanced users.**Their audience is comfortable with shell scripts and batch files. (Lurch is for the classroom, a word processor with feedback shown visually in the document. See “User Interface,” above.)

We want Lurch to *help students learn to prove, *and existing proof-checking software serves a technical user with different needs*.* We’re targeting students in their first proof-based courses, giving frequent, immediate, clear feedback on the steps in their work. *That’s *the part of the mathematical community we’re excited about reaching.

Now you know what our mission statement says. In a future post, I’ll talk about how close we are to that goal, what we’re lacking, and how to help!

]]>