Boolean Algebra.com

[Barb Frison]

I was refactoring old code and encountered several IF conditions that were way too complex and long and I'm certain they can be simplified. My guess is that those conditions grew so much because of later modifications.

Try Logic Friday 1 It includes tools from the Univerity of California (Espresso and misII) and makes them usable with a GUI. You can enter boolean equations and truth tables as desired. It also features a graphical gate diagram input and output.

The minimization can be carried out two-level or multi-level. The two-level form yields a minimized sum of products. The multi-level form creates a circuit composed out of logical gates. The types of gates can be restricted by the user.

I need to know because I find the whole thing confusing. I'm in a college algebra class right now though some of the boolean algebra seems quite basic (commutativity, associative properties, etc. ie. basic algebra). I was reading The Art of Assembly Programming but then I hit the boolean algebra chapter and got frustrated. The author uses what I consider to be "arbitrary" symbols for his operators though I don't know what operators are ordinary. I'm used to C++ !, &&, and operators for the NOT, AND, and OR operations respectively. There's typo's and other things in the e-book which make it more difficult to read.

The point being, is that chapter absolutely necessary to learn? Are there any beginners x64 assembly programming books out there? This computer has an AMD 64 bit processor. I was reading Programming from the ground up but its for linux. I could follow that one because its easier to read but I tried to compile an example and it did not work. Even with changes to the code to make it windows compatible, no dice.

Yes, it is very important to understand. Boolean algebra is used to implement hardware and is also responsible for many assembly operations. && is And, is or, ! is not, etc. Google the truth tables for all of these, they're very simple. You only need a simple base really to understand the operations as you see them.

I am recently studying computer science and I was introduced into boolean algebra. It seems that boolean algebra is used to simplify logic gates in hardware in order to make the circuit design minimal and thus cheaper. Is there any similar way that you can use it to reduce the number of code lines in your software in higher level languages like C++, C# or any other language?

Note it is not a tool for just simplifying logic gates in hardware as well. However, it can sometimes be used for such cases (as well as for the opposite, or for completely different purposes).

For example, if your program contains an overly complicated boolean expression or sequence of conditionals, boolean algebra might help you to simplify the expression and the surrounding code. But that does not necessarily lead to less lines of code. In fact, sometimes complex one-line boolean code snippets get more maintainable when you split them up into several lines of code, and boolean algebra can help you to do this correctly.

So IMHO your question is like "can I use a pocket calculator to find the shortest route when traveling from A to B"? Sure you can, when you take a map with distance information for individual roads and use the calculator to add them up, and then pick the route with the smallest sum. But you could also use the calculator for finding longer routes, or for calculating completely different things.

This is a list of checks on the object person, and will exit the function as soon as one of those is true. The meaning of that is pretty clear, and anyone that reads it, even a non-programmer, can understand what checks we're doing.

So no, you do not reduce the number of code lines using boolean algebra. You use it whenever there is a binary choice to be made. If your problem is complex, you are going to have a lot of choices in your software solution.

Well, OK. The reason electronics engineers want to reduce the number of logic gates in a circuit is probably a matter of construction cost and operational performance of their final product. They are building the very thing that will do the work in the end.

When you are programming in any language other than assembly, the computer in the end will not execute your code, but a transformed version of it. This transformation from the programmer friendly language to the computer friendly language may be called compilation. Boolean logic is indeed used by the compiler to achieve operational efficiency.

You may code in assembly and do the compiler's job yourself, but on a day-to-day basis, it becomes less and less worth the hassle. Modern compilers know more and more of the tricks, and better than you.

On the contrary, if you ask whether there exist a similar practice in higher-level languages, yes, it's called refactoring, which means applying well-defined transformations to code chat change the structure and not the behaviour. In the 90s, Martin Fowler published a book that is a catalog of probably the most recurring basic refactorings in object languages.

However in case of High-level languages it may result in more problems. HLL languages are designed for readability and ease of understanding. You can simplify your several lines of code into a single one, but it will become unreadable and complex, so much more time is required to grasp the idea of the code.Most of compilers perform such kind of optimizations by default.

All in all, I suggest not to think a lot about reducing lines of code, but consider behavior of the program in runtime, memory usage and architectual design. Generally when you are applying Boolean Algebra to your circuits you are acting as a compiler for most of existing languages.

Usually, breaking a complex line into multiple, simpler lines will increase readability without significantly reducing performance. Only if benchmarking shows that there is a unacceptable performance issue should you refactor to increase performance at the expense of readability.

To add to the existing discussion, including its idea that fewer lines is good if it also enhances readability, I'll just mention one thing you can do with Boolean algebra in a language where all values all truthy or falsy, such as Python. Here's a FizzBuzz solution in Python, written in a style that's achievable in just about any high-level language:

In this case the benefit came because the same function needn't be mentioned in two lines of which only one is called, and we therefore seek an expression that equals this argument in every scenario, and we can get it using this not-all-that-little-known fact about how Python handles Boolean operators. I'd hate to have to write

You'll find several Python solutions to FizzBuzz here, using this trick but differing in what further Pythonic tricks they use to shorten the code even further. (They even show you can do the whole thing in one line, once you learn what happens when you multiply strings by integers.) These might be less conducive to readability, although of course they're worth learning how to do.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

Two years ago my team and I set out to reinvent semantic SQL engine technology. This technology has been a core competency of legacy Business Intelligence (BI) tools like SAP Business Objects, MicroStrategy, and IBM Cognos. Essentially, an SQL engine allow Data Architects to map underlying datasources and data models into simple semantic ideas that any business user could understand.

For example, a field called cust_email in a table called c_attributes from a data warehouse named prod_wh could be reduced to a single concept Customer Email. Now a business user simply has to request data for customer email. A semantic SQL engine would take Customer Email as the input and automatically translate that into a query against the correct set of tables and datasources. The user does not need to know the underlying table name, the field name, the datasource name, or even how to write program an SQL query.

In recent years innovation on semantic SQL engine technology had stagnated. Customers begun abandoning ship for faster solutions like Tableau or Mode. The problem was sophistication without simplification.

Our first insight was to embrace SQL. Rather than be an all or nothing SQL engine we would work in tandem with the user. Our engine would generate Multi-Pass SQL from simple user inputs, but we would let the user edit the generated SQL queries. These edits would then be fed back into our engine as a learning mechanism. A marked difference in approach from the existing BI tools.

Not so fast! Even with this innovation we had a big problem. SQL engine technology and Multi-Pass SQL in particular is heavily patented and highly litigious. A scrappy little startup with limited resources needed something more.

Naturally, a criteria like this involving Measures (fields requiring aggregation) gets split up among several queries where each query gathers a set satisfying one Measure filter criteria. For example, you will have one query that gathers a set of customer emails where the spend is greater than one hundred and another that gathers a set of customer emails for digital ad views less than two. The problem is that you only want the set for the last 90 days. We found that most BI tools in this scenario will only apply the last 90 day filter in a final pass after having combined all of the queries.

Intuitively this looked like an algebraic problem to me. A few googles and I discovered Boolean Algebra. It turns out databases have already been using boolean algebra to rewrite queries on a per query basis. A BI tool could add additional optimizations on top of this by simply being aware of the entire query set and how each field is used (Measures and Dimensions).

c80f0f1006