Output of "Look In Map" should NOT be inverted

[fabric]

Many common functions include a "found" or "exists" output. Examples include:

• Get Variant Attribute
• Element of Set?
• Config file VIs (Read Key, Write Key, Get Key Names, etc)
• Chek if File or Folder Exists

Why then does Look In Map provide an inverted ("not found") output? Wouldn't it be better if it was consistent with other similar functions??

This is most frustrating when replacing existing code using variant attribute lookups with equivalent maps. "Look In Map" is pin compatible with "Get Variant Attribute" except for that one inverted output! This has caught me out on more than one occasion...

[crossrulz]

We (the LabVIEW Champions) pushed back on NI about this when Maps and Sets were being developed.  The rationale for inverting here was to match it being an error (key not found being the error).

[fabric]

Hmm... In that case shouldn't the Element of Set output be an error too? ("element not in set")

It is not so much the choice of logic that irks me, just the ugly inconsistency with other functions (especially with Get Variant Attribute).

[JimChretz]

Even if you were right, they can't go back for retrofit reasons. There's probably already bunch of exising code using that reversed logic that will upgrade to newer LabVIEW versions so you don't want to create a bug in those softwares...

[tst]

---

@JimChretz  wrote:

Even if you were right, they can't go back for retrofit reasons

---

That shouldn't actually be a problem. NI can add mutation code which would simply add an invert after the output if the source VI is from LV 202x or older or when backsaving

[_carl]

This has been driving me nuts too!

It's most frustrating to me when I feed this output into a case structure, and I'm looking at the false case and thinking to myself "ok....this is not not found...so....it is found....".  The extra mental gymnastics (while simple) make it quite easy to make simple mistakes.

Any time I wrap these into a bigger function I'll invert the output and just pass out "Found?".  Makes life easier.

[fabric]

... and I'm looking at the false case and thinking to myself "ok....this is not not found...so....it is found...."...

Exactly! It feels like the "correct" approach to naming should always be the one that results in the simplest mental logic:

• If the name of any given terminal is implicitly inverted ("not found") then it will often lead to double inversions. The trivial example of wiring a boolean terminal to a case structure is a good one. Conceptually, the FALSE case is a double inversion.
• If the intention is that the terminal represents an error (as seems to have been the case with "Look In Map") then the terminal should have instead been named "error". The meaning is the same, but it avoids any conceptual double inversions.

(I'd be surprised if this "simplest logic" idea wasn't a documented naming principle somewhere...)

In any case, I still think the natural choice for "Look In Map" is to un-invert the logic rather than just un-invert the name.

[wiebe@CARYA]

... and I'm looking at the false case and thinking to myself "ok....this is not not found...so....it is found...."...

Exactly! It feels like the "correct" approach to naming should always be the one that results in the simplest mental logic:

• If the name of any given terminal is implicitly inverted ("not found") then it will often lead to double inversions. The trivial example of wiring a boolean terminal to a case structure is a good one. Conceptually, the FALSE case is a double inversion.

So we change 'not found' to 'absent' and everybody's happy? Error doesn't seem right...

[AristosQueue (NI)]

I've been monitoring the impact of this decision over the last few months. Obviously, "found" is the intuitive direction for the setting, so it was a conscious decision by R&D to invert it, and I've been curious if we got it right.  It's close, but in code I get to review or write or see in bug reports, the current direction is eliminating more "Not" inversions than the other direction would eliminate. Being able to directly treat that as logically equivalent to an error state appears to me to be generally desirable.

"Change 'not found' to 'absent'" might be a good idea. Changing terminal name does pose some scripting risk (terminals can be looked up by name), but it might be worth doing for the avoidance of "not not" mental gymnastics.

[Manzolli]

True for 'not found' or 'absent'? Looks to me like using double negative sentences, when the result is false. May be a crazy idea but how about creating a sibling function (new name) with a true output for a found item. Both will coexist for a while, but only the new one in the palette, like stacked sequence. After a while the first one can be changed to deprecated.

[McQuillan]

I just spent a while tracking down a bug caused by this... so I thought I would join the chat.

Whilst I appreciate the anti-pattern may reduce the number of "Not" inversions. I believe that to be secondary to the natural instinct that TRUE = Good/Positive "operation was successful". I would much rather have more "Not" inversions on my block diagram and be able to think straight.

I get that Errors are TRUE when there's an error that's [generally] Bad/Negative. However, in LabVIEW, we tend to wire error clusters to case structures which textually say "Error", "No Error". If Errors were like LV-collections, the syntax would be "No Error = True". Which hopefully we can agree would suck.