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).

[PJM_Labview]

I do not know about others, but I don't understand what you are proposing.

[X.]

A reconfigurable boolean operator.

One with which one can think in the following way:

if x = TRUE and y = TRUE, I want answer 1;

if x = TRUE and y = FALSE, I want answer 2;

if x = FALSE and y = TRUE, I want answer 3;

if x = FALSE and y = FALSE, I want answer 4;

where answer n (n = 1, 2, 3, 4) can be TRUE or FALSE (that would be a classic boolean operator), but more interestingly could be an integer value such than when connected to case structure, I can deal with the different cases without having to nest case structures within case structure.

Right now, one has to check out the logic table for each boolean operator to figure out which one to use. I usually don't bother (because I know I won't remember the logic table of the other exotic operators next time I take a look at the code) and try to use the standard AND or OR instead. Oftentimes that means I need to invert my inputs and compute two or more different boolean operations to feed their results into one of the nested case structures.

I envision this has having a reconfigurable "matrix-like" interface as depicted above.

[elset191]

You could try something like this

With two booleans you have 4 cases, 0-3

[David_L]

Kind of like a Karnaugh Map or truth table.  Not a bad idea for people who are used to the concept from college, but I'm not sure how many would use it.  Are K-maps used in industry much?

[X.]

elset191, that is a possible implementation but it is not easily legible (at least for me). Without your comments within each case (X = False, Y = False), which you would have to paste each time you use this implementation, there is no simple way to remember what case 1, etc corresponds to. A self-explanatory icon would let you jump to the case of interest easily (not mentioning that you would save a lot of wiring and typing).

Guys, what I am just saying is that except for logicians out there, the set of boolean operators seems useless FOR PRACTICAL PURPOSES and might be replaced by this new function... Again, we've lived decades without it, we probably can survive another one without it.

But since it is an idea exchange forum, and supposedly looked at by NI for ideas to improve the usability of LV in the future...

[dthor]

I'm with elset191 on this one. What he's created is a bit register, which is used a hell of a lot in hardware (though those are generally 8 bits). I've seen them used mostly for communication: things such as Service Requests and Status Registers. Back in my FPGA programming days, I used them for the core logic, too. Anyway...

It's true, if you're not used to dealing with bit registers, then looking at them takes a bit of work. I think a temporary solution for what you want is similar to this:

It's the bit register that elset191 suggested, but modified so that the case structure has text instead of numerics - easier to read with a quick glance.

Personally, I use the boolean operators to solve logic problems. They do take up a bit of space on the BD, but then I just turn that into a subVI and am happy again. 🙂

[JackDunaway]

dthor: A strategically placed Coerce to Type will remove the need for introducing a Front Panel Control and a FSS. 😉

[X.]

All right, now that we've agreed on the functionality (I'd like it a bit more general so that it applies to more than just booleans though) so let's make it a native function! 🙂

[AristosQueue (NI)]

I REALLY like this idea!!!!!

This is the sort of truly innovative idea that I wish we saw more of on the LV Idea Exchange. This is the sort of ease of use leap -- harnessing the "graphical" part of the LV language -- that keeps LV ahead of the text programming paradigm. Thanks for this idea.

Of course, it isn't getting many kudos. Don't worry -- high kudos can push a feature forward in the pack, but low kudos doesn't necessarily kill it. And this definitely caught my attention.

Minor point: The node has to be growable. A two-input solution is actually pretty tractable with the existing prims. It's the 3-input and higher solution where this beauty would really shine.

[X.]

Unfortunately, I can't give kudo to this idea...:-)

I thought only very briefly about a more-than-2-input version of this function and since the matrix-like interface extension to more than 2 dimensions is cumbersome, I gave up on it.

However, my initial motivation when thinking about this function was, as I mentioned before, to handle multiple input parameters and move on to different cases depending of the different sets of inputs. I suppose that in this case, an interface in which the user would define the finite number of interesting cases (intervals or discrete values?) and the corresponding result might be sufficient.

In other words, if the input parameters (whichever types they are) are P1, P2, ... Pn, the user would have to list the cases he/she is interested in as:

case 1: P1_min < P1 <= P1_max, length(P2) = 3, ..., Pn >  0 Result 1: "Case 1"

case 2: P1: no constraint, P2 ="Hello World", ..., Pn: no constraint Result 2: "Case 2"

...

case m: P1< 0, P2: no constraint, ...,  Pn: no constraint Result m: "Case m"

All Other Cases: Default Result

I am not sure that would be general enough (or too general?) but that would probably be useful enough. Again, that would be more of a reconfigurable Express VI type of interface than a function at this stage, but maybe both could be provided (a simple binary operator and an extended version of it)? Whether we would be better off writing our own VI for that is definitely an open question!

My 2 cts.