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.
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.
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.
Now if you have a conditional sort, why not a conditional swap? This means both arrays end up with 10 elements.
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.
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.
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.
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.
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.
@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
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.
I have added a normal indexing above and below and a conditional (True) above and below. That works for me.
Indexing above and belowConditional (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.
But then an index below a normal conditional is now harder to discern.
@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?
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).