Invertable case selector

[SteenSchmidt]

Hi,

Sometimes I end up with a double negation when selecting in a Boolean case structure:

Double negations are notoriously hard to understand and thus a source of misunderstandings. Therefore I most often eliminate such double negations by dropping in a Not operator:

For these situations it would be nice to be able to invert/negate the case selector by right clicking on it, just as with several of the built-in Boolean functions:

I'm not concerned about performance, as I'd expect the compiler to compile the bottom two cases equivalently. It's more that you're forced to move nodes about less in the suggested case, if you find that you have to negate the case selector.

The drawback obviously is that you move away from the expected behavior of a case structure, but I think it's a small tradeoff. There are many good ideas floating around the Idea Exchange which touches on the subject of negating Boolean inputs that you currently cannot negate, but I couldn't find one that suggests negating the case selector, and I have needed that many times...

Cheers,

Steen

[Intaris]

The negate circle on the structure is kind of hard to see. 

[SteenSchmidt]

Agreed that the circle can easily be missed, but I stuck with it since it's the same as on the other Boolean functions. I tried several other glyphs and colors, but didn't find a really good one yet. Do you have any suggestions?

/Steen

[crossrulz]

I think I'd rather have the option to invert the boolean terminals.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Invert-Option-in-all-Boolean-Terminals/idi-p/1281058

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Negate-input-on-boolean-functions/idi-p/1084159

[SteenSchmidt]

@crossrulz: In that light the Boolean case selector is also a Boolean terminal - which then should be invertible .

The Boolean output on the Empty String/Path? primitive would be among those that are suggested to be invertible in the ideas you link to, but in my case that wouldn't solve anything, as I also need that value non-inverted outside the case structure in my images. It would just move the Not operator to some other location in my code.

/Steen

[crossrulz]

Yes, I am just moving where the NOT happens.  I'm just saying I'd rather have it on the primitives than the case structure.

[SteenSchmidt]

Copy that.

[RavensFan]

I say just flip the cases.  If I have text that becomes too confusing, then I put a label in each case of the structure that more clearly defines its condition.  One case would have "badge style defined"  (a statement, not a question) and the other case would have the label "badge style not defined".  Having the invert circle on the case selector just confuses things that much more.  "Does True now mean true before the the invert or after"?  You've now effectively turned your confusion based on a double negative to a triple negative.

[SteenSchmidt]

@RavenFan: Yes, I use labels inside each case as well, if the structure labels and case selector values isn't enough explanation. I don't agree that a neg on the case selector results in a "triple negative", the original double negative (the structure label + the False selector value) is removed, so you're back to just a single negative - just as if it was a Not operator in front instead.

In my illustrated situation the free label inside the case would just add to the confusion IMO:

I feel it's much easier to understand when the Boolean selector is inverted; you don't need the free label inside the case structure, and you have a sentence construction without double negatives ("FP badge style defined? True!"):

I fully accept that the invert bubble is an orphan that shouldn't be on the case selector (so, idea dismissed), but I maintain my opinion that the inversion of the Boolean value going into the case selector improves readability . I'll stick with my Not operator then.

Cheers,

Steen

[JackDunaway]

Your specific example uses Empty String/Path? -- this function, and two others, commonly require negating negative logic; let's hit it at the source and offer a positive logic alternative. No, it doesn't solve 'the general case', but solves your example and (presumably) a good chunk of your and my other cases of sub-optimal Boolean logic 🙂

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.