Darren's Weekly Nugget 07/10/2006

[Darren]

Have you ever used the Implies function?  It's on the Boolean palette:

Every once in a while I'm writing conditional code that needs to execute as follows:  If X is True and Y is False, do something.  For all other cases, do something else.  When I'm writing this kind of code, I always reach for Implies.  When I see it on my diagram, it's always immediately clear to me what's going on...which is good, since Boolean logic was never my strong suit.

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 07-10-2006 11:54 AM

[tst]

I never used it, but my usual method is to use the compound arithmetic primitive (although that one doesn't play nice with the auto tool from the last nugget ) and set it up to make it "clear" what's happening. If it's even a bit complicated, I just drop a comment saying what happens when.

[Will.D]

I haven't thought about boolean 'implications' since pretty much the first year of my degree!

Thanks for reminding me.  I'm sure I'll be able to use this for a number of things...

[agill]

In formal notation, we often use the arrow for an if, then statement.  This is the exact same thing except in boolean form.

if X, then Y 

translates to 

~X v Y  (not X or Y) 

or, X =>Y

or X implies Y

Drawing the truth table shows this:

X | Y | Result

----------------

1 | 1 | 1 

1 | 0 | 0 

0 | 1 | 1 

0 | 0 | 1

Or in other words, X is a sufficient condition for Y (but not necessary).

I onced wondered, does labview have the the double arrow (IFF)? X<=>Y?

which means IFF X then Y

 or 

X is a necessary condition for Y.

Then I realized: Heh, stupid question, as the boolean function is simply just X. by itself 🙂

[altenbach]

Yes, implies is proably a bit underused, but I have used it in the past, (e.g. "current boolean to X, previous state from shift register to y" senses a False->True transition but not a True-> False transition).

As tst mentioned, the functionality can be easily duplicated by a compound node, which might look a bit more familiar to some of us. 😄

Message Edited by altenbach on 07-10-2006 10:58 AM

[Darren]

Yup, but when I see Implies on the diagram, it's immediately clear to me that "oh, here's a situation where I'm looking for a specific T/F combination of these two Booleans."  That's not as clear to me if I see a Compound Arithmetic set to Or with one of the inputs negated.  🙂

Of course, I'm no computer scientist...perhaps the latter is more understandable by those hooligans.  😉

-D

[agill]

On the contrary, I'm an Electrical Engineer...  Not quite computer science, my friend.  And I find that it's extremely helpful to have a strong background in boolean algebra and logic, especially when working with digital systems, but I'm a third year undergrad, so what do I know ;).

[Kevin_Price]

Different strokes for different folks I guess.  I consider the "implies" operator to be nifty but overly obscure.

I actually have used the "Implies" primitive a few times, but have lately been making an intentional habit of preferring the compound Bool arithmetic.  To *me*, the negated input reads more literally. ((~A) OR B) seems more intuitive than (A-->B).  Especially if I'm trying to explain it to anyone who hasn't studied formal logic.

I've learned and accepted the idea that an 'implies statement' with a False premise will always evaluate to True, but I've known quite a number of people who just can't seem to grok it.  Granted, they typically aren't people who look at source code, but for me it seems simpler to stick with the basic AND, OR, NOT stuff when feasible.

Not looking to proselytize, just adding my 2c.

-Kevin P.

[altenbach]

---

@Kevin Price wrote:

..., but I've known quite a number of people who just can't seem to grok it. 

---

I have to admit that every time I used "implies" so far, I had to do a double-take on the context help to make sure I don't mix up the x and y inputs, since they are not interchangeable. 😮

(Of course we can just blindly hook it up, then use the switcheroo trick from an earlier nugget to swap away until the results are as expected ;)).

Using the compound node, you can have the inverted input on the top or bottom, and it is always clear what's what. 😄

Message Edited by altenbach on 07-11-2006 08:56 AM

[tbob]

I have to agree with Kevin.  Although I have studied digital logic heavily and use it quite a bit, I never did understand why the imply function was even invented.  The wording makes little sense.  The word imply is defined as "To express or indicate indirectly" according to Dictionary.com.  To me, this should have a logical meaning of "if A is True, then B is True" or something like this, which is redundant.  To me, the "not A or B" logical function has little to do with the definition of imply.  I'll stick with the real "not A or B" compound logical function which is understood by a vast majority over the imply function.