It’s just logic

Don't do this
Do this

conjunction (∧)

if(p) q else false 
p && q 
p ∧ q

conditional/implication (→)

if(p) q else true 
!p || q 
¬p ∨ q

negation of conditional/implication

if(p) !q else false
p && !q
p ∧ ¬q

negation of conjunction

if(p) !q else true 
!p || !q 
¬p ∨ ¬q

disjunction (∨)

if(p) true else q 
p || q 
p ∨ q

negation of inverse conditional/implication

if(p) false else q 
!p && q 
¬p ∧ q

inverse conditional/implication

if(p) true else !q 
p || !q 
p ∨ ¬q

negation of disjunction

if(p) false else !q 
!p && !q 
¬p ∧ ¬q

if(p) true else false
p 
if(p) false else true 
!p 

6 Responses to “It’s just logic”

  1. Jörn Zaefferer Says:

    Those are also very useful in JavaScript, maybe even more there, because you only have c-style if-else constructs, not the enhanced Scala style.

  2. Tony Wooster Says:

    Fore!

    Aside from the entries that return purely true or false, this is a wonderfully obfuscated way to program. Returning values from a logical construct might work, but it’s a worthless way to communicate a concept.

    No cookie for you.

  3. Tony Morris Says:

    Tony,
    I’m not sure what to make of this. Are you advocating some of the constructs that I have denoted as “don’t do this”?

  4. Jake McArthur Says:

    I think the intent was that both p and q are boolean values.

  5. Tony Morris Says:

    I think the intention of the post was not understood.

    In each entry, is an italicised if/else construct on the first line. One the second line is a correction and “less obfuscated” expression that is equivalent. On the third line is the same expression written using denotational semantics. Each entry has a name that derives from first-order logic.

    How can be it be so complicated?

  6. Tony Wooster Says:

    Eegh. Early morning crankiness without coffee makes me write some aggressive things. Sorry.

    What I was taking exception to was the opening line of “Don’t do this. Do this” equivocating statements like:

    disjunction (V)

    if(p) true else q
    p || q

    Which I incorrectly read as an equivalence between these statements, which isn’t strictly true in most programming languages. My post was an argument against golf programming — wherein if p or q are anything but boolean values, you begin returning objects which can be acted upon, which to me is obfuscated.

    p || q more correctly maps (in many languages, as far as I can recall) to: if (p) p else q

    So, in an obfuscated way, you could write something like:

    var = (p || q)

    Instead of:

    if ( p ) var = p else var = q

    Which is semantically clearer. Again, sorry for the dickish post. Hope this makes it clearer.

Leave a Reply