Interface talk:Classical propositional calculus

unidirectional builders
Part of the reason why I added a section called Unidirectional builders to Principia Mathematica propositional logic is that some of them seem to be missing from Interface:Classical propositional calculus. Some are used a lot in the proofs in that module, as late as ConjunctionComposition. If there is a more powerful mechanism which replaces them, I didn't see it. The ones which are particularly used are *2.05, *2.06, and the typical usage could be expressed in the following rules:

stmt (addCommonAntecedent ((q → r)) ((p → q) → (p → r))) # rule form of *2.05 stmt (addCommonConsequent ((p → q)) ((q → r) → (p → r))) # rule form of *2.06

The contrast between these rules and applySyllogism should make it clear that they are functioning as builders, and calling them Syllogism is actually kind of confusing (at least, it was for me at first). I suppose I'd add *2.05 and *2.06 as CommonAntecedentAddition and CommonConsequentAddition (and get rid of Syllogism by that name, as ImplicationTransitivity is what most people think of as syllogism). Metamath's set.mm calls these rules "Inference adding common antecedents in an implication" (imim2i) and "Inference adding common consequents in an implication, thereby interchanging the original antecedent and consequent" (imim1i), so my proposed names seem plausible.

I also find that my general unidirection builder for implication is in set.mm as imim12i. Based on set.mm it seems like it gets some usage but not as much as imim1i or imim2i. We could always add it later if we miss it. Kingdon 03:42, 14 February 2010 (UTC)


 * I didn't even think of unidirectional builders. So, sure, why not. Especially if we suspect we need them quite often.


 * (I'll comment on your other remarks later when I have more time.)


 * --GrafZahl (talk) 18:59, 15 February 2010 (UTC)


 * Done. Based on the number of usages in Principia Mathematica propositional logic, these are indeed needed often. As for imim12i, looking at its metamath proof confirms what I suspected: that this one amounts to just one application of each of the other two, plus a syllogism.  So we can wait on that one unless it seems to be common. Kingdon 20:53, 15 February 2010 (UTC)

Things I thought of adding
I'm not sure the case for adding any of these is strong, but I thought I'd mention them.


 * applyComm from Principia Mathematica propositional logic. Of course you can import, then apply ConjunctionCommutativity and the implication builder (once), and then export, but that can seem like a lot of work.  The case for this is weakened by the fact that it seems to be used only a handful of times in set.mm (where it is pm2.04) and fewer times than I realized in Principia Mathematica propositional logic. We can see whether the four-step process mentioned above becomes common before worrying about this.


 * Proposition *5.1. Whitehead and Russell put this in a list of theorems used "very frequently". set.mm says about 13 usages (it is pm5.1). Its friend, *5.21, and some variants in set.mm (theorems whose names start with pm5.21) seem to get used a bit more, but I didn't look closely at the variants (probably more like separate theorems than applications of *5.21).


 * and . I was scribbing on a piece of paper and thought I might have use for these, but I'm not sure I was even handling dummy variables right, or how often it would come up. Sounds quite safe to put this off until there is a more pressing need.

In general, my first instinct is to err on the side of waiting and seeing, especially until we have a bit more experience. Kingdon 04:26, 14 February 2010 (UTC)


 * Basically, I just went along and put stuff into the interface I thought would be needed, and other stuff which seemed nice to have for the sake of completeness. I never did a usage analysis of set.mm. So if set.mm usage suggests that something should be in, then by all means, we should put it in. Generally, we need to weigh the benefit of having shorter proofs in modules importing this interface against the extra work of proving new statements in modules exporting it. I suspect there will never be many modules exporting this interface. In order to show that some other propositional calculus can prove the statements of classical propositional calculus, you'd more likely export the principia mathematica axioms, as they are only a handful and Principia Mathematica propositional logic already exports this module. So I'd say when we already know that something will be useful for us later, we can put it in now. For the rest, waiting and seeing may indeed be the best strategy.--GrafZahl (talk) 23:08, 15 February 2010 (UTC)


 * I agree that most modules would probably export the axioms rather than Classical propositional calculus, although that's a bit of a self-fulfilling prophecy if Classical propositional calculus gets really big. My reasons for wanting to keep it short are mainly: (1) make it easier for humans to find/choose a theorem in the list, avoiding a needle in the haystack problem, (2) technical limits in mediawiki, web browsers, and I think jhilbert in terms of how big a page can be and still perform well. Of course if something gets used, it should exist somewhere, but we can worry later about how to divide things up. Kingdon 01:00, 16 February 2010 (UTC)

Name of eliminateLeftBiconditionalImplication and friends
I have two big gripes with the name:


 * The left/right nomenclature. We currently explain it this way: "The naming convention here is that when we think of p ↔ q as consisting of two implications, we call p → q the left one and q → p the right one." but I think "forward" and "reverse" would probably be clearer. Left and right could just as easily be thought of as the way the arrow is pointing (which would be the opposite meaning from the current one).


 * It is way too long for something which is used constantly. set.mm has a bunch of theorems which are modus ponens for the forward implication, modus ponens for the reverse implication, etc, etc, but I am kind of hoping that if we give eliminateLeftBiconditionalImplication a shorter name, we can avoid the need for lots of theorems of that sort.

Therefore, I'm thinking "forward" and "reverse" to replace eliminateRightBiconditionalImplication and eliminateLeftBiconditionalImplication, respectively. I'm not as worried about extreme conciseness for BiconditionalImplicationRightElimination and BiconditionalImplicationLeftElimination, so something like BiconditionalImplicationForward and BiconditionalImplicationReverse would be OK with me. I know that naming rules after nouns rather than verbs goes against the grain, and I normally try to resist the urge to make everything short, but I'm taking what feels like a slightly extreme measure to try to avoid proliferation of theorems (either for inferences, as mentioned above, or for both directions of a theorem which we also have in the biconditional). Kingdon 04:37, 14 February 2010 (UTC)


 * Hmm, the names were actually meant to refer to the eliminated arrows. Obviously, I got it mixed up. About the name length in general, I must say that the extremely short names in set.mm always stumped me a little. Hence I chose longer names, similar to naming schemes in software APIs. But I must also admit that I usually avail myself of an external editor (which has an autocompletion feature) for writing longer wiki texts. So let's try to find some middle ground, especially for the most often used rules. In this specific case, what do you think of  and  ? It seems to me that the words "forward" and "reverse" already imply that an implication will result.--GrafZahl (talk) 23:08, 15 February 2010 (UTC)


 * Actually, you did the left/right convention one way in Interface:Classical propositional calculus and the other way in Principia Mathematica propositional logic, so when I removed the discrepency, I apparently kept the version you didn't like as well. I totally agree about short names in general. My desire to have this one short has little/nothing to do with ease of typing; it is about ease of reading, and has to do with how common it is for a proof to contain something like "p q ConjunctionCommutativity eliminateBiconditionalReverse". I sort of wanted the name to express the direction being kept, rather than the one being eliminated, but am having trouble thinking of a good wording. Perhaps , although that kind of assumes a lot of context which eliminateBiconditionalReverse is explicit about. So unless I think of another proposal I guess I'll go with   and   (and   and  ). Kingdon 01:33, 16 February 2010 (UTC)


 * Renamed. Kingdon 14:11, 18 February 2010 (UTC)

Is everything here needed, especially BiconditionalConjunction?
Some of the theorems here I don't quite get. I'll mostly pick on BiconditionalConjunction. This looks to me like it is lacking motivation (unlike BiconditionalDisjunction which has a nice relationship with exclusive or and the like), and would be easy to replace with the combination of BiconditionalImplication and ImplicationDisjunction if needed. I didn't find BiconditionalConjunction in set.mm. This affects the above named theorem and the rules convertFromBiconditionalToConjunction, convertToBiconditionalFromConjunction, and introduceBiconditionalFromDisjunctions.

A few others which might also be subject to further discussion/investigation are SyllogismInConsequent (assuming we get CommonAntecedentAddition, discussed above), DisjunctionLeftElimination (a lot like CaseElimination), and the five similar ones of Tautology, Contradiction, NegationImplication, True and NotFalse (I'm kind of guessing we need/want some of this set, or even others like Abs or *3.24, but I'm not sure which ones). Kingdon 05:02, 14 February 2010 (UTC)


 * What I intended with  and the like was to display some interrelations of the truth functions. Think Boolean algebra. Whether they are actually used it not so important in this case. I really think we should have those, and maybe even more. But not necessarily in this interface. I'd be content with moving them to some extra page. As for , I think we can live without it as case elimination is indeed the more common proof method.   and the like probably belong on the same page with  . I'm not sure right now about   (it's late and I'm tired).   weakens the hypothesis and is therefore not always applicable, so we need the more tedious   to build an instance of  . But maybe we don't need such an instance very often.--GrafZahl (talk) 23:08, 15 February 2010 (UTC)


 * A separate interface may be a good idea, not just for statements but also for some of the discussion about equivalence classes and such (which I find jarring, as they are statements about a metatheory or a model, not about a relation which is a kind of set in an axiomatic set theory which is built on this interface itself). But as for the specifics:


 * I'll leave BiconditionalConjunction alone until it gets moved. Things like DeMorgan, BiconditionalDisjunction, and most of the others would stay here even if there is a separate interface, for practical reasons and perhaps because they are more deep (in the sense of not quickly following from theorems we do have). Kingdon 02:22, 16 February 2010 (UTC)


 * I've gotten rid of .  If the goal here was a parallel with conjunction or some other reason for thinking there should be a disjunction elimination, I'll note that the introductory textbook forall x has a "disjunction elimination rule" (page 111) which amounts to

stmt eliminateLeftDisjunction ((H1 (p ∨ q)) (H2 (¬ p))) (q)
 * In other words, modus ponens for disjunctions. Now, one could always just apply DisjunctionImplication and then modus ponens, so I'm not saying we need it, just that it makes a better parallel.


 * With respect to SyllogismInConsequent, you might be right that avoiding it is more work than one extra line (I didn't try to work it out). I was perhaps overreacting against set.mm which has a FooInConsequent variant for almost every propositional calculus theorem they have. We'll leave in SyllogismInConsequent for now. If no one is using it, we can always get rid of it later. Kingdon 02:22, 16 February 2010 (UTC)

formula vs wff
OK, I probably should stop this level of nit-picking when there are bigger fish to fry, but does anyone object to renaming wff to formula? As I understand it, some authors define formula to mean any string of symbols and well-formed formula (wff) to mean one which matches the syntax rules shown here. I'm proposing the other nomenclature (which I didn't make up, although it perhaps is somewhat less common) in which a string of symbols is just a string of symbols (there isn't really a frequent need to refer to this concept anyway) and a formula is the thing which matches the syntax rules. My motive is mainly to avoid the acronym  in favor of the more self-explanatory. Kingdon 23:26, 16 February 2010 (UTC)


 * I defined  as an alias for  . There is a small drawback: all exports now need to define the same alias. But hopefully there won't be many exports.--GrafZahl (talk) 10:34, 18 February 2010 (UTC)


 * Sounds like a good compromise. Thanks. Kingdon 12:43, 18 February 2010 (UTC)

Get rid of Importation and Exportation?
Any objections to getting rid of the Importation and Exportation theorems (in favor of Transportation, the biconditionalized version)?

Our general policy, in most of the file, is to supply only the biconditional, and expect that many times it will be followed by eliminateBiconditionalForward or eliminateBiconditionalReverse.

Of course the rules "import" and "export" would remain. Kingdon 14:10, 15 March 2010 (UTC)


 * No objections. I mean, it's bound to happen very often that a proof step involving a biconditional will be followed by one of the eliminators, but it's such a trivial step that it shouldn't be a nuisance.--GrafZahl (talk) 17:45, 15 March 2010 (UTC)


 * Done. A lot of extra trivial steps can add up, but in this case I think the cost of convenience is too high (for one thing, it isn't very convenient if there are so many theorems you have trouble remembering all their names). Thanks for the prompt response. Kingdon 02:14, 16 March 2010 (UTC)