The Manipulative Nature of Manipulation Rules

As we dwelve deeper and deeper into the myriad of logical equations, it helps a great deal to be able to recognize certain patterns, and to understand what, and what is not actually equivalent to one another.  And so with the introduction of conjunction, disjunction, as well as negation, it becomes more and more important to know these logic laws like the back our hands!

Maybe not the approach I had in mind.

The manipulation laws are actually quite intuitive, and don't really need that much memorization as long as you know what you're looking for.  I found them  to be very similar to the rules of addition/subtraction, so below are some of my analogies I came up with:

Identity: P ∧ (Q ∧ ¬ Q) ⇔ P
P + ( X + (-X) ) = P

Commutative: P ∧ Q ⇔ Q ∧ P
P + Q = Q + P

Associative: (P ∧ Q) ∧ R is ⇔ P ∧ (Q ∧ R)
(P + R) + Q = P + (Q + R)

DeMorgan's: ¬ (P ∧ Q) ⇔ ¬ P ∧ ¬ Q
-(P + Q) = -P + -Q

Naturally this doesn't cover all of the laws, such as the quantifier distributive and idempotency, but it helped me easily recognize some patterns, especially if I treat the conjunction/disjunction symbol like a plus or minus sign!

Start of CSC165: Ambiguous Sandwiches

    Hello TA, and presumably anyone else who's bored enough to read this.  This is the weekly SuyLoG, where I'll be posting thoughts, feelings, and problems that arise throughout CSC165.  I'll be your guide into the tumultuous mind of yours truly, as I try to decipher the hieroglyphics that we call quantifiers and the like.

These are things that mean things.

    Thankfully, in the first two weeks we started out nice and slowly, easing into the course by discussing things like the importance of ambiguity vs. precision.  Intuitively, I think we all expect that being completely precise would be the ideal.

In truth however, as anyone who has written a computer program might profess, being precise can often being exceedingly tedious, whether it's having to look up the exact name of a function, or trying to track down that ever-elusive semi-colon.

Ah, the joys of the high-precision language of programming

    So practically speaking, being ambiguous is fine, because we can use context clues to quickly and effectively understand what is trying to be conveyed.  But sometimes, the ambiguity of our language can cause confusion.  Like in sandwiches.

High in deliciousness, cholestrol,
and confusion.

    A seemingly innocuous sentence.  "The sandwich tastes delicious".  But from the perspective of computer scientists, this sentence lacks pertinent information, or what we call an open sentence.  This means we can't evaluate the sentence without more information.  While you may be tempted to say that if S is a set of sandwiches, and D is a set of a delicious elements, then the statement claims:
Some elements in S are in D.  WRONG.  

    Because the sentence doesn't want any old sandwich, it wants the sandwich.  And seeing as we don't know what sandwich they're talking about, we can't evaluate it!

    But wait, this is where things get confusing.  Where do we draw the line in the sand, and say that the sandwich has been fully specified (and therefore we can evaluate it).  If we were to say "This or That sandwich was delicious", then surely it's implied we should know what sandwich they're talking about.  But does that not also apply to "the" sandwich?  In fact, even taking it to the next level like "The bologna sandwich I just ate was delicious", might not be accurate enough.  Perhaps he ate two sandwiches at once, and you have no idea which sandwich he was referring to!

    Of all the things to be confused about in a Computer Science course about mathematical expression and reasoning, you really wouldn't think it'd be a sandwich.