# Hooray for Boolean Algebra!

## By

on October 9, 2007 4:07 PMI knew when I enrolled in Introduction to Logic that the course was going to be usable long into my career, and in truth, I've done quite a bit of work with Boolean Algebra in almost every program I've ever written. What I didn't expect to do again, was to write out, solve, and simplify pure boolean equations ever again. But today, I spent a good portion of the day doing just that.

Here at WSU not every student receives a mid-term grade. In fact, very few do. The rules, expressed in English, were very simple:

- Graduate Students don't get Midterm grades
- Only for Fall and Summer Terms.
- The Spokane Campus doesn't have mid-terms
- Freshmen with less than 28 total hours
- New transfers (in their first semester at WSU) excluding seniors (students with 90+ hours) and excluding Vancouver

However, when I dug into the code, I noticed that we weren't using the same equation every where to determine if a student was to receive a mid-term grade or not! Not only that, but I'm not sure that the equations in use were even correct! There were two places that I worked from when trying to fix this problem, our Class Lists application, and the Grading Submission Application.

ClassLists: ~GradStudent & ( NewTransferStudent | CreditsUnder28 ) & ~SeniorCredits & ( ( (Pullman|TriCities) & ~Summer) | (FreshmanStanding & Vancouver) )

GradeSubmission: (((Pullman | TriCities)) & ~Summer) | (Vancouver & FreshmanStanding)) & ( NewTransferStudent | CreditsUnder28) & ~SeniorCredits

Not only were these kind of a mess, but they weren't even equitable equations. So, I basically just threw them out and spent some time designing and testing a new equation. This included a few false starts as I tried to keep the equation as simple as possible, and didn't include all the rules I needed to initially, not to mention a few other projects needing direct attention, but eventually I was able to come up with, what I believe, is the simplest equation that fulfills our rules.

Here is what I came up with: ~Summer & ~GradStudent & ( ( ~(Vancouver | Spokane) & ( (FreshmanStanding & CreditsUnder28) | (NewTransfer & ~SeniorCredits) ) ) | (Vancouver & FreshmanStanding & CreditsUnder28) )

This Equation made me wish so, so much that Vancouver didn't have to be different from Pullman or the Tri-Cities. No such luck though, and I ended up with a more complex equation than I really wanted. Still, I think it's clearer than the old one, and since it's the same everywhere it's used, it should be easier to maintain. Plus, any new campuses will automatically be included, as long as they follow the 'standard' method of determine midterm eligibility.

Then, of course, was the minor challenge of substitution my Boolean Algebra equation with a SQL statement that amounted to the same thing. Most of my Boolean Variables could be represented very simply in SQL, as I had kept the data organization in mind when designing the equation, but the NewTransfer variable had to be represented by looking at 3 different fields in the database, which also required some boolean algebra itself. That term basically expanded to (NoWSUCredits & HasCredits). Actually, this wouldn't have been a problem at all, but the data is stored in the database as strings, which required me to do a lot of unnecessary CASTing. If the data had been stored correctly according to it's type, things would have been much easier. Maybe there is a fringe case that explains why it was organized the way it is, but I haven't seen it.