Simplifying Boolean expressions

[A.A.A.]

There are alot of applications that require the use of Booleans, and when the boolean expression gets complicated or large it will be a headache on the programmer.

LabVIEW should try having a De Morgan law "function" or at least a way to simplify complicated Boolean expressions. Although it won't be used as much, it will be a handy tool for any electronics/programming course.

For instance, Partial fraction expansion isn't used regularly but when it's used it helps save time.

These are simple examples but can get more complicated. For example, usage 2 can have more input (e.g. 4) it will have 16 possibilities which have different simplified code.

USAGE 1: User wires some input on the block diagram, when the simplify button is used, it simplifies the complicated code to a simple one ( noting that it is not the unique solution as shown in USAGE 3)

USAGE 2: If for the application, the user changes the value of the input and he gets different output; this table can get the simplified; or the "best fit" for the number of data present.

In http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/16975/tab/rich, I wanted to compare that  Partial fraction expansion vi is not widely used except for certain applications yet it is important and beneficial.

Same goes for this idea.

[tst]

I suspect I'm not the only one who doesn't know or understand this law (and this doesn't really help), so can you explain your suggestion with more detail and maybe include an image showing what such LV code might look like and what its results will be? Is this something which can't be accomplished today by using the existing compound arithmetic primitive or by using a subVI? How is it going to benefit users?

[altenbach]

The way I understand the law, it does not really simply an expression, but just rewrites it in a different way. So what is the gain?

A more general simplification of boolean expressions would be an implementation as proposed here. This seems more practical.

Maybe I am missing your point. I would recommend to be much more specific and detailed. Add examples and pictures to the idea to help us really understand what you are proposing.

(I don't know why you are suddently start talking about partial fraction expansion at the end, that seems completely unrelated. Are you trying to justify the need for an obscure function with the fact that LabVIEW aready has some other obscure functions? 🐵

[A.A.A.]

I couldn't add a pic so I posted a new idea here http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Simplifying-Boolean-expressions/idi-p/1891007 Sorry again for duplicate posts

[tst]

I think that your examples from the other thread can be solved with the other idea Altenbach linked to and with the compound arithmetic node. The other idea doesn't exist yet (although read all the comments there), but using the compound arithmetic node will considerably simplify the code in your use cases 1 and 3 (be sure to read all the help for it), so it's probably not needed anymore.

[A.A.A.]

Probably it can simplify the code, but I think these are two ideas have different usages. Let's think in this way. At least once, an engineer will take an electronics course that is related to logic gates, mosfets ,diodes (except probably Civil engineer). Well, When I took this course last year, I remember that I had to deal with simplifying logic expressions e.g. A’.B’.C.D + A’.B.C.D’ + A.B’.C.D’ into C. (A’.B’.D + D’. (A’.B+A.B’)) where (.) is and (+) is or (') negate. This example is simple.. there are other harder examples. The first idea is to make a simplify button or a structure similar to a formula node that would simplify it. I don't think there is any program or software that does such a thing (if there was any, the professor would have taught us to use it.) so I think National Instruments can try tackling such a "formula node" because I can assure you that students from most universities will use such a structure for their course. Critics might think that an increase of lets say 1K electronics course LabVIEW users in the world doesn't justify the release of such a structure. But in my opinion, the earlier an engineer starts using LabVIEW the better it is for NI. As for the second usage I posted, I think it is also slightly different than X. or Darin.K. This usage is directly related also to a electronics lab. Here, the user inputs in a "table" the different values of the input and different values of the output and the vi results in the simplified logic expression. It's like tackling a black box example. For different inputs you have different outputs. e.g. 4 inputs and 1 output=> 16 different cases and 16 different output readings then the vi gets the expression of the simplified logic equation also this is used for an electronics course. In my opinion, adding X., Darin.K, A.A.A. ideas is a very useful update for LabVIEW and will increase the number of electronics course users noting that no other software has implemented this before. If you are still not convinced with the undergrad student example, consider an advanced electrical engineer who wants to implement and draw a circuit for his application using different amps ex, schmitt trigger... With the inputs and outputs known, he uses this function and gets the simplified logic equation and then he buys the necessary chips. I'm not sure if any of you had to go through this scenario, but it's useful for some applications. Best

[Brian_Powell]

I actually find this suggestion intriguing.  In a prior life, I studied Automated Theorem Proving, and along with it, a bunch on propositional and higher-order logics.

The intriguing part, though, is that you're asking for a tool to rewrite LabVIEW code into an equivalent form.  Not just diagram cleanup, but expression cleanup.

If I understand correctly, you want to be able to select a Boolean expression in LabVIEW, and rewrite the code in, for example, Conjunctive Normal Form (or Disjunctive, or Negation, etc.).

It would be plausible for someone to do this today with scripting.  I'm not sure it's likely to bubble up in priority for NI to do this, but I think it would be an interesting programming challenge for someone to implement and share.

And it would be mind-blowing to try to Skolemize, too. 🙂

It would also be interesting to think about other (e.g., numeric) expressions to simplify with a similar approach.

[altenbach]

Brian, yes something like this would need to be part of a full featured symbolic math engine. Why stop at booleans? We would simply select a code fragment...right-click...simplify. 😄

In some ways we already have that, but hidden from view. The compiler already does common subexpression elimination, loop invariant code handling, etc. so, under the hood, the code might not resemble operation-by-operation what has been wired by the programmer anyway.

However, should all this really bubble up to the visible diagram? It might need to significantly rearrange things and modify and rewire potentially well layed out code.

Should the engine be able to automatically simplify or remove unecessary operations (such as these) from the diagram?

I am sure that 20 years from now, advancements in artificial intelligence will make these things possible. How about a VI analyzer that not only finds the problems, but also fixes them all without user intervention? 😄

[PhillipBrooks]

does this suggestion share anything with these posts?

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/General-Comparison-Operator-as-an-Express-VI/idi-p/128...

http://forums.ni.com/t5/LabVIEW/Truth-Table-Node/m-p/1293680

[A.A.A.]

@PhillipBrooks: This suggestion tackles also boolean expressions and the way to simplify the equation. Didn't you learn in electronics courses ways to simplify boolean expressions? I remember that I used K maps to simplify expressions and I don't think its hard to program K maps. example: a table having 4 inputs and an output for different cases. from this it is simple to get the K map then the simplified boolean expression. Case 1 can be changed to case two when all cases (0-1) where replaced for the inputs then the Kmaps were drawn then the simplified expression is found. I think this is what is being taught in most electronics courses in universities. @ Brian,altenbach there has to be a pioneer in this field and I don't see why LabVIEW can't step further.

[X.]

It is indeed different than the idea I proposed. But although I see where you are getting at, I am afraid that this could lead to "reverse" code obfuscation since, unless you are coming out of college, boolean logic is not really easy to decipher at first sight.

The advantage of my suggested approach is that it mirrors the average programmer train of thoughts: if I have this and that condition, I want to do this; if I have this other one and that other one, I want to do that, etc. In particular, it dispense you to handle a NxN matrix when you have N inputs (all the undefined cases yield the "default" result). The problem I (X) have is how to write down these multiple cases using boolean logic. The suggestion I made was to provide a more natural (to me at least) way of handling these multiple cases. If you read down the thread, you'll see that I went quite far in terms of explaining the functionalities I was dreaming of.