« Tech Digest

Tips for Technologists #8: Know Your Boolean Math

Tips for Technologists is a series aimed at teaching you to engage with technology in best way possible. You can see all the Tips for Technologists articles here.

By Nick Ruffilo

Tip Level of Difficulty: Intermediate/Advanced

Don’t run away, I promise this won’t be boring!

I am over simplifying a bit, but most of programming comes down to this concept:
If SOMETHING
Then do THIS
Otherwise
Do THAT

Since the results are boolean (two options), the SOMETHING has to be boolean. That means that it has to be a statement that results in True or False. Programming languages do a great job at allowing you to turn anything into a boolean. For example, the language Javascript has an IsNumeric() function that returns true if your parameter is a number, and false otherwise.

Basics of Boolean

Boolean algebra has some fun concepts, like the Big O, but I want to cover the most basic concepts here. These basic concepts are actually used nearly everywhere, in fact, they are even used in google searches (ex: you can use NOT and AND keywords in search results to help filter results). Boolean Algebra actually contains quite a few functions but these are the important ones:

  • AND — And will return true when both conditions are met. Big Bird is Big AND Yellow. If (Big AND Yellow AND Bird) “We most likely have a Big Bird”. In programming languages this can be represented as “&&”
  • NOT — Take the opposite of whatever you have. If our result is true, NOT makes it false. Not is represented in many languages by the use of !. If (Big AND NOT Yellow) “We don’t have Big Bird.” In programming languages this is represented usually as !.
  • OR — Returns true when at least one of the conditions is met. False when none are. If (“Logged in to facebook” OR “logged in to twitter”) “I’m not going to get work done today.” In programming languages this can be represented as “||”
  • XOR — Short for exclusive or. Will return true when only ONE of the conditions is met: If (“Nick is talking” XOR “Ed is talking”) “We can understand what is said”

Order of Operations <- KEY CONCEPT

This is important for business types and programmers. In fact, I’d say this is one of the biggest reasons for communication failures between business and tech types. There is actually a set of standards for order of operations but not all programming languages follow that (especially the lower orders). The statement: “if (Big AND Yellow OR Green)” may not evaluate the way you think. Let me first explain the issues with that statement.

I have a Big Yellow ball. What’s the outcome? True. That was simple.
I have a Big Green ball. What’s the outcome? Possibly True.
I have a Green ball. What’s the outcome? False? Probably not!

Lets see about how the statement could be interpreted first:

  • (Big AND Yellow) OR Green
  • Big AND (Yellow OR Green)

See the difference? In one, if the object is Green, it will ALWAYS be yes. How do we solve this problem? With parentheses. Out of the ways to interpret, we pick the one that matches what we want and use that.

Ok, back to how this causes communication issues. Programmers are trained, from the moment they start coding, to constantly figure out where the parenthesis will go. When you run your code, it isn’t going to yell at you and say: “You may have told me to do something you didn’t want.” It will simply run the code, and provide results. Not until the results found don’t match expectations can you start to find out why there is an issue. Because of this, programmers tend to be explicit in how they deal with boolean choices.

Whereas natural language seems to have a different order of operations. I’ve seen written specifications that say they want “Item A, Item B, and Item C or Item D”. A programmer looking to reduce his task load may simply: “I can do D really quickly, so I’ll ignore A, B, and C.” Things get even worse when requests are not clear and concise. Coders aren’t robots, but the clearer the communication, the better the results (in both business and technology). People writing specs/documentation often have a 100% clear picture in their head, but write a 1-paragraph description of the problem/solution. “Move the button to the top” and “Align the button in the top/left hand corner of the screen with a small (5px) space between the corners” is a clearly different spec. Also – did the initial one want top middle? Top left? Top right?

Not is extremely important

The NOT operation is extremely important. In programming, it is a great way to ignore edge cases. If (Big AND Yellow AND NOT Real) “Much more likely its Big Bird.”. People tend to focus on what they DO want. When you are communicating a vision you have, it may be clear in your head, but often it is not for the people you want to build it. Try using a few NOT statements. I want to set up a website, but NOT something complex. I want to be able to give it my own look/feel but do NOT want to have to come up with my own styles, I’d like to be able to customize it from pre-made templates. Sounds like a wordpress site to me. NOT helps you limit options and give a clearer picture of what you do want.

Getting a bit more advanced

Up to now, I’ve been high level and basic, but below I will discuss some more in-depth topics. Just a friendly warning.

Format your crazy statements

Most programming language allow for multiple lines for a single statement. This allows you to break-up or indent functions as you would code so that you can more logically read it. It also helps you work through logic better. Take for example the following if statement (pseudocode based off javascript notation):

Unformatted:

if (IsNumber(phone_number) && (phone_number.length == 10) && (!phone_number.contains(“555″) && (isValidAreaCode(phone_number) || isInternationalPhoneNumber(phone_number)) { }

Formatted:

if (
IsNumber(phone_number)
&& (phone_number.length == 10)
&& (!phone_number.contains(“555″)
&& (
isValidAreaCode(phone_number)
|| isInternationalPhoneNumber(phone_number)
) { }
Beyond being able to read things better, it also lets you see where you may have missed an opening or closing parenthesis. Also – I’ve found that when asked for “what is the logic behind our phone number validation” copy/pasting code like that is actually readable to non-programmers — especially when you follow a logical function naming convention — so you are saved time in writing them in readable English and possible translation issues.

Break things down

If you have a very complex statement, especially if it is not giving you the results you need, break it down by using variables. You can then output these variables to the console to debug. Using the above as an example:

var is_a_number = IsNumber(phone_number);
var is_10_digits = phone_number.length == 10;
var is_a_movie_number = phone_number.contains(“555″);
var is_valid_area_code = isValidAreaCode(phone_number);
var is_international = isInternationalPhoneNumber(phone_number);

console.log(“This is a number: ” + is_a_number);
console.log(“This is 10 digits: “+ is_10_digits);
console.log(“This is movie number: “+ is_a_movie_number);
console.log(“This is a valid area code: “+ is_valid_area_code);
console.log(“This is international: ” + is_international);

if (is_a_number && is_10_digits && !is_a_movie_number && (is_valid_area_code || is_international)) { }

This can tell you what, if any issues you have. Maybe is_a_number is failing because the user added “-” to their number, or your search for 555 fails when the number is 111-222-4555 (which should normally be considered a valid number). Having everything in one statement becomes very difficult to debug/tweak. While the above code is more lines, it is MUCH easier to read/tweak. The IF statement is clean and readable, and the above statements support that If.

 

Want more Tips for Technologists?  Join the daily mailing list and see additional content at ZenOfTechnology.com.  You can also see other Tips for Technologists articles here on Publishing Perspectives here.

This entry was posted in Tech Digest and tagged , . Bookmark the permalink. Both comments and trackbacks are currently closed.
  • SIGN UP NOW!
    Enter your email address below to receive daily news updates from Publishing Perspectives.
    Click here to learn more about our newsletters
  • Monetize Your Backlist

    Organized by Publishing Perspectives

    Hear experts from publishing and technology discuss strategies and tools you can use to generate more revenue from your backlist content.

    What: Monetizing the Backlist event
    When: 9am–1pm on April 24, 2014
    Where: Scholastic Headquarters, NYC

    Buy your tickets now!