General Comparison Operator (as an Express VI?)

[X.]

I rarely use boolean operators to solve logical problems. Instead, as I would suppose the majority of users, I use them to respond to a set of conditions and perform actions in response to different cases.

The current set of operators:

is, to say the least, quite difficult to use. For instance, for the third operator, the help window provides the following explanation:

Now if you invert one of the inputs, good luck to figure out at first glance, when you revisit your diagram, what the outcome of the comparison will be.

In fact, what we need is some kind of matrix operator for which we type in the output of the comparison of A (input 1) and B (input 2) for the different cases:

Here I have supposed the inputs are "modified-booleans" with an "undefined" case, and the output of the comparison is an integer value, just to illustrate that operators for non-booleans could be treated the same way.

In the strict boolean operator case, there would be no "U: case and the output would be T or F. It would be a simple matter (I guess) to let the boolean operator icon show the outcome of the comparison in a way similar to something like that:

In general I find useful to have non-boolean outputs (as in the matrix above where integers were used) to be able to handle complex situations. Of course the icon would have to reflect the values selected by the user...

Which brings the issue of the configuration of this operator. Considering that the interface for this operator would be quite sophisticated, it would make sense to provide it as one of the Express VIs (such as the "Formula" or "Comparison" functions).

[minnellac]

I'm not so sure about the implementation of the solution, but I definitely feel the pain of working with the logical operators. I've been known to draw all sorts of logic tables to try to figure out how to make the inputs meet the desired outputs. It would be much simpler if there was just a way to map one to other. Neat idea.

[Darin.K]

I am not sure I like the idea yet, but if you want to play around with the two input, boolean truth table node I have thrown together a prototype here.  I'll have to think about how to implement the more general case.

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

I think I would prefer the ability to expand the case selector to have multiple inputs.

[falkpl]

I have contemplated an idea like this and thought it was a great place for express vi and scripting. 

I Like the K-Map express node.

step 1 list all boolean inputs and outputs name them.

step 2 fillout the truth table given the matrix Inputs x outputs.

step 3 generate the express vi, essintially the k-map solution to the truth table,

   The inputs to this vi is the cluster or array of booleans, the output is the cluster or array of booleans.

This can easily be converted to a boolean logic made from nana gates, the kmap is the solution to your logic problem.

[X.]

falkpl, that sounds great, but keep in mind that you may want more than just boolean inputs or outputs. I'd really like a enum output for instance, and I suppose that any kind of input type could be used as well (think of enums or strings, for instance).

[falkpl]

I would have to think about an enum - this is like a fully connected state diagram?  The boolean would be relativly simple to do the kMap would yield the logic for the truth table and the it is just a matter or scripting the nand connections (digital designers do this already).  The enum could take some thought on implementation.

[X.]

falkpl,

the problem I see with a generalization of my simple matrix design (nicely implemented by Darin) is that it becomes cumbersome starting with 3 inputs, as it requires the user to fill in a 2x2x2 matrix. I can't think of a simple interface/visualization of the different cases and corresponding outputs...

However, I can imagine that most of us would be happy to define the results of finite subset of combinations and attribute the value "undefined" (or "to be processed by a dedicated case") to the rest. Having "True" or "False" as outputs would be VERY limiting, in my opinion. Being able to define an enumerated list of possible outputs would allow connecting the result to a case structure. That could indeed also be implemented (if I understand your last sentence) as a "generalized" case structure with MULTIPLE inputs, and an interface providing a way to handle different combinations of inputs... But that maybe a whole new can of worms!

My 2 cts,

X.

[X.]

Here is my suggestion for an interface to a multiple input version of the operator (thought of as an expandable node but configured as an Express VI):

The output could be a Boolean if the user defines only two possible results (For instance "T" and "F" for it to be easy to manage) but I think it would be much more powerful to provide an enum output (reflecting the user's choice of description given to each result, not necessarily "Result n") that could be directly connected to a Case Structure. A "Default" result could (should?) also be defined.

In the case of more than N = 3 or 4 inputs (2^N combinations would result in a quite a long autopopulated table), it is likely that not all combinations will need to be enumerated. I think the user would be mostly interested in a few sets of input values, all the other outputting a common "Default" result. In this case, instead of an autopopulated table, the interface should offer to define only that subset of interest (i.e., offer an empty table in which the user would only enter the case he/she is interested).

As interesting would be a node with non-Boolean inputs, but the interface might need to be a bit more sophisticated to account for the different kinds of operation these other types of input can be used with (e.g. comparison for DBL, etc).

My 2 cts,

X.

[X.]

I have elaborated a little on the above design in the related thread started by Darin here

[slipstick]

This has my vote! Working with the boolean operators is always a struggle for me. I like steering my state machine with boolean outputs of pass fail from other evaluation VIs and right now have to consult an Excel table of values.

[X.]

Let me reproduce my latest suggestion here (where it belongs!):

The object is an expandable node (currently limited to Booleans, but I would welcome an expansion to other types):

The wire names I have indicated come from the last connector/control they are connected to (or their own label, if defined) and are those which will appear on the interface (see below). If there is no particular name (for instance you connect a constant with no label), the name of this input defaults to something like "Input N".

Double-clicking or right-clicking on the object would open a configuration VI looking like this:

Notice that this is bit of an extreme case (10 inputs!), but I am just playing around. Arguably it will be used for a handful of inputs in most cases (like we use the other expandable nodes in LV for). What I consider a MUST HAVE is that the input names are reproduced on the interface (so that there is no need to look back at the diagram to figure out which one is which), and the output is a user-definable enum. I think it is best to define this enum in the interface rather than on the BD (as implemented by Darin), but that's my personal bias.

Again, I don't think one may necessarily want the whole Truth Table displayed. In most cases, there will be only a few cases (combinations of inputs) that will result in non-trivial (or default) outcomes. This interface allows to define each of them readily: you simply select the inputs that are "TRUE" in each case, press the "New" button, which adds an entry in both the Truth Table and the Results array. Next you adjust the Result you want for that specific case. Repeat for as many cases as you are interested in. All the others will result in the default outcome.

You may want to have a "Sort" button to rearrange the cases, etc... but I think the basic functionality would be covered by the interface above.

Now, the question is whether this will find a sympathetic ear at NI 🙂

My 2 cts (well, a whole $ by now).

X.

PS: I have removed the horizontal scrollbar in the Truth Table because I did not want to allow for more columns than there are inputs (as scrollbar in a 2D array would allow to do inadvertantly), but in a customized interface, it would be easy to prevent this from happening...