LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
fabric

Output of "Look In Map" should NOT be inverted

Status: New

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??

fabric_0-1617240144803.png

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

10 Comments
crossrulz
Knight of NI

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


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
fabric
Active Participant

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
Active Participant

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
Knight of NI Knight of NI
Knight of NI

@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


___________________
Try to take over the world!
_carl
Member

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
Active Participant

... 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
Knight of NI

... 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)
NI Employee (retired)

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
Active Participant

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.

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
McQuillan
Active Participant

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.