IFL2: Propositional truth trees

[Reposted] The first edition of An Introduction to Formal Logic did logic by trees. The main text of the second edition will do natural deduction, Fitch-style. But chapters on truth trees will still be available, as two online appendices. And these appendices will, indeed, together make a brisk stand-alone introduction to logic by trees for a reader who knows the basics about the languages of propositional and predicate logic.

Here, then, is the first appendix, on propositional truth trees (pp. 27). This is a slightly revised version from the one posted a few days ago. It is free to use and distribute. And the plan is for it to remain freely available, through the IFL2 page. Needless to say, all further comments/corrections gratefully received.

5 thoughts on “IFL2: Propositional truth trees”

1. Congratulations! Breezing through, this seems to be a very nice presentation, pedagogically suitable for first year philosophy students with no mathematical or computational background. It could even be used for school kids of a much younger age. For this reason, it would be great if you could get your publisher to allow this appendix to appear with free access on your personal website (so you can control it); a lot of people would use it and it might even serve as a good advertisement for the book.

Here are a few small comments, mainly on terminology.

Literal/simple: It is rather cavalier to abandon the by now quite standard term ‘literal’ in favour of ‘simple’. Nor do I see it as an improvement: the noun ‘literal’ is strikingly unusual while ‘simple’ is a portmanteau term, used for many different kinds of simplicity in different contexts.

Working backwards: A great term with an honorable ancestry. Nevertheless, it might be worth pointing out that we can also think of the procedure as working top-down as opposed to bottom-up, or as outside-inwards as contrasted with inside-outwards. Many views of Mount Fuji help appreciate its beauty.

For the same reason, it might be worth saying somewhere that truth-trees are sometimes called by the more explicit name of ‘semantic decomposition trees’ – this could be done near the end, where the contrast with parsing (i.e. syntactic decomposition trees) is made.

Naked: At the opening of section 2 this means ‘unannotated’, so that all formulae are naked; but at the beginning of sections 2.2a and 2.3 it means ‘not beginning with a negation sign’.

Incestuous: Being pedantic, if I may, a family tree may rejoin without being incestuous in a legal or moral sense, if the distance between fork and join is sufficiently great. Indeed, population statisticians assure us that almost all family trees are like that if one goes back a few hundred years.

Closed branch: This is indeed the standard term, suitable for mathematicians, but rather dull for humanities youngsters. I find that students cotton on much better if they are called ‘dead’ branches, with the explicit contradiction called a ‘crash-pair’.

Page 24 point b: insert ‘in’ before ‘which’.

1. * I find ‘crash-pair’ a bit too ‘cute’. It is memorable and could appeal especially to younger students, though, so I’m of two minds.

* On the whole, I prefer ‘literal’ to ‘simple’, but they both draw the line at a somewhat odd point: one unary operator but not a binary one.

However, many people these days will be familiar with the way ‘literal’ is used when talking about programming languages, as well as with non-technical uses. The technical use in logic doesn’t fit all that well with these other uses. I think that argues for ‘simple’. ‘Simple’ seems more a natural description than a technical term. (Is that outweighed by arguments for ‘literal’? I don’t know.)

* I like (and agree with) the ‘pedantic’ point about family trees. Even without ‘incestuous reunions’, however, family trees are rather odd as trees. When a tree is a data structure, a node has one parent and zero or more children, not two parents.

* I was a bit uneasy with the parallel terminology of semantic / syntactic decomposition trees, because while the semantic ones do some decomposing along the way, they do something else too. (Something that was just a semantic decomposition tree would just show how meaning was built from component parts.)

But I thought I’d better look at what the Truth Trees doc said about parse trees, and I saw this: “ignoring the relatively trivial matter of which way up we draw them.” Wait a minute! You draw them a different way up?

So I looked at what the IFL2 draft said about parse trees. Or, it turned out, what it called parse trees. They aren’t what I’d call parse trees. This (see the pictures) is a parse tree. While the things in IFL2 may technically be trees, they’re written to look like proofs in one of the (to me) almost unreadable notations that relies heavily on horizontal lines.

1. If the Truth Tree appendix is meant to be able to stand alone, then it shouldn’t say “the construction/parse trees we met before”, and the discussion in 2.6 seems excessively complex. It should be pointed out somewhere that proof trees are disjunctive and that there are other uses of trees that aren’t, but combining that with talk of up and down and two other types of tree seems likely to be more confusing than helpful.

(To be fair, IFL2 does turn the unreadable proof-like “trees” into something that looks like trees. However, even the they’re construction trees, not parse trees.)

BTW, the IFL2 draft says wffs are ‘molecular’ or ‘atomic’, and the atomic ones are single letters. I think that avoids the problems with ‘simple’ and ‘literal’.

2. R: Yes, I agree that the discusion in 2.6 seems excessively complex, and have much simplified. More importantly, I’m persuaded that the IFL2 discussion of constructional histories/parse trees is mishandled. The parse will now appear the right way up, wff-to-be-parsed at the top.

D & R: OK, the mild witticism about incestuous family trees isn’t worth keeping, given your points!

D: Yes, the double use of “naked” wasn’t intended.

D & R: I’ve dropped both “simple” (too unspecific) and “literal” in this context.