LabVIEW Idea Exchange

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

Conditional Indexing to optionally output the false condition (along with the true one)

Status: New

I find myself writing this type of code more and more recently.

 

ci current 2019-08-13_13-53-21.png

 

It would be nice to have an easier way of achieving this (for instance either of these below could work):

 

ci new v2 2019-08-13_13-53-33.png ci new 2019-08-13_13-53-33.png

 

Showing the false terminal could be done with the right click menu

 

ci new menu 2019-08-13_14-15-43.png

 

 

 

 



  


vipm.io | jki.net

33 Comments
fabric
Active Participant

I'd go one step further and allow True, True & False, or just False! That would satisfy requests for the ability to invert the sense of the condition terminal.

 

I also quite like the syntax of positioning the inverted output below the condition terminal.

NickNZ
Member

Hi

I am not keen on your example drawings, either the inverse "o" on output or the F tacked on. But it got me thinking how to build on this idea. 

 

I am also concerned about visual appearance if there is another normal conditional above. Not much differentiation. E.g.

confusing.png

 

 

 

 

Perhaps something bolder? Rather than calling it Conditional (True & False) Call it Conditional Sort, as you are effectively sorting into two (ragged) arrays based on the Boolean. E.g.

 

Conditional Sort.png

Now if you have a conditional sort, why not a conditional swap? This means both arrays end up with 10 elements. 

Conditonal Swap.png

 

I tired to make the X to look like the swap values, and array [ ] are a bit further apart. Would a conditional swap be useful?

 

If you want a conditional false, this is quite obviously different to the current Conditional (True). I like the idea of the False being consistently under the conditional input. But need to avoid confusion if there is another indexing terminal above. 

 

Conditonal False.png

Or do you just use conditional sort and let the compiler sort things out if you only need the false array?

 

I do feel the current Conditional (True) has to keep the same form factor for backwards compatability. 

 

Nick

 

 

 

PJM_JKI
Member

Nick,

 

I was not in love either with the visual aspect of the tunnels, but I was trying to keep them small.

 

I like your approach [for T & F tunnel] (although the result is larger). I did a minor tweak so that it did not overhang on the side of the for loop.

2019-08-14_11-36-51.png

Note 01: I dont think we absolutely need the False condition alone, because it is very easy to achieve by changing the original condition (in my example from a "greater?" to a "less or equal?").

Note 02: regarding the swap; I dont think I ever had to do this.



  


vipm.io | jki.net

AristosQueue (NI)
NI Employee (retired)

I'll leave the idea open, but I will say that this is all stuff that NI considered when we added the feature. We rejected it back then because of readability. I've posted about this on many features -- trying to understand a diagram is harder (checked with various usability studies we've done) when a) the graphics for features are hard to see or b) the graphics are unusual and rarely used. When we have an easy and obvious way to write code that doesn't require any specialized syntax, we'd have to see a significant gain in efficiency or some other attribute to overcome the "it's easy for someone reading your code to understand" advantage.

 

In this case, the Not primitive is easy to drop and recognize. It's easy for someone to miss the "not circles", sufficiently so that we debated removing them from nodes in the transition to LV NXG. Ultimately, they were retained, but they are bigger.

 

Speaking personally, I'm still not convinced that we should have them. I'm not convinced that they do more good than harm to overall LV usability. This idea presents a bunch of different possible syntaxes. If the simple "not circle" is insufficient for some reason, then I think the burden for this idea shifts from questionable to negative. If the input Bool can simply be negated without introducing other syntax that must be understood, then I probably wouldn't kick too hard.

 

But I'm just one voice in this chorus. Let's see how the kudos develops.

cy...
Active Participant

@NickNZ: the conditional sort is misleading as it filters, not sort. the swap is even more confusing, wouldn't the output be wrong with the tested logic?

 

@AQ: seconded

 

@fabric: if it is either just true or just false (to save some BD real estate in instances where the logic in most of the loop structure is true with the exception that the false residuals to be passed out of the loop) with ? and ! symbol to differentiate

 

but just a hunch, felt like it could lead to some oversight and possibly some unintended consequences

CY (expired CLAD)
NickNZ
Member

Hi

thanks for feedback. I wanted to try to improve on the proposed appearance, but agree with @AQ about readability. 

 

@CY, agree conditional filter is a better name than sort. I was looking for something other than Conditional T/F.

 

@PJM, I saw there was room for another terminal and wondered what a swap would look like - after more thought - I agree I don't think its worth it. It appears the swap primitive is pretty efficient anyway and would be much more readable than this option. I withdraw this idea. 

 

The current conditional (True) option was a major step forward. Is the additional visual complexity and right click menu options worth it above what we have now? I do sometimes find it hard enough already if there are non conditional indexing terminals close by. I enjoyed thinking about this idea, but I think overall I reserve my kudos on this one. 

 

Nick

PJM_JKI
Member

@AQ: I agree that the proposed graphical semantic is not awesome and getting that right is important.

 

Here is another idea (it leverages the boolean true and false constant semantic)

 

ci new v3.png                         2019-08-16_12-15-32.png

 

This *may* works better.

 

Thanks



  


vipm.io | jki.net

NickNZ
Member

@JPM  I like that concept much better. 

I have added a normal indexing above and below and a conditional (True) above and below. That works for me. 

Indexing above and belowIndexing above and belowConditional (True) above and below.Conditional (True) above and below.

Might be better to make the conditional True consistent as well and fill it. This would make the conditional terminals stand out more too. Which I think is good.  

Conditional True filled as well.Conditional True filled as well.

But then an index below a normal conditional is now harder to discern. 

Normal index at bottom.Normal index at bottom. 

cy...
Active Participant

@PJM_JKI better compared to the initial, but kinda reinforces the readability issue, refer comment below

 

@NickNZ your example kinda show how bad the readability can be when the terminals get close to each other 

 

unless the glyph includes a transparent "spacer" that enforce separation of the terminals, or it could really hurt readability. perhaps another question to be added on for discussion: what about last value and concatenate tunnels? 

 

still kinda have a feeling something undesirable will happen as a result of this. For example, if condition is not true, but yet not the false condition, ie. test: x>y, x=NaN or thermocouple readings when junction-opened. What would it be then, when false 'negatives' will be passed on? 

CY (expired CLAD)
AristosQueue (NI)
NI Employee (retired)
PJM_JKI: I like the direction you're going in the latest pictures. Maybe increase the overall height of the border tunnel (instead of being exactly three terminals tall, make it 3 terminals + 4 for rows of black pixels, 2 above and two below)? That way it divides itself better from other indexers (and it would be trivial for LV to always draw the splitter tunnel on top z-plane).