LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
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...

--
Chris Virgona
8 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).

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

--
Chris Virgona
wiebe@CARYA
Proven Zealot

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

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.