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

[PJM_JKI]

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

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

 

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

[fabric]

make it 3 terminals

Yes, 3 "normal" terminals of exactly 8px height! Not some whacky 11px variant that precludes any possibility of tidy upstream wires 🙂

[PJM_JKI]

@AristosQueue "...make it 3 terminals + 4 for rows of black pixels, 2 above and two below..."

Like this?

FYI: I previously  made the end terminals a pixel wider and taller to allow for enough room to see the solid background. See the image below to see the difference before and after (note: I kept the wire vertical alignment identical though).

This is what it would look like for various data types. The semantic seem to work ok.

[GregSands]

Would it also help to change the question mark in the middle - perhaps like one of these:

[cy...]

@PJM_JKI

wonder if clear or solid spacer can distinct them better? and how will the last value and concatenate tunnels look like? 

is it for indexing terminal only? then the "false terminal" enabler in the context menu will become conditional (indexing only) on top of "conditional" enabler as an option.

is it applicable for false only case as well? as shown on the bottom right of the figure, above the ???

or is this proposed to replace the current  conditional indexing tunnel?

[AristosQueue (NI)]

Fabric wrote:

> Yes, 3 "normal" terminals of exactly 8px height! Not some whacky

> 11px variant that precludes any possibility of tidy upstream wires 🙂

Consider the use cases where you've needed to get both the true array and the false array... if we go with the "question mark in the middle" model, the code will take a pair of wires (the bool and the value) and change its layout (two arrays with a space in between). The bool and the value are unlikely to arrive from the same originating node, and the expansion of the bottom terminal will already preclude the error wire from going straight across for nodes that produce out of the second terminal (which is common [for example, Dequeue Element]). So the most likely pattern, I suspect, is for the *bool* wire to run straight and the value wire to bend down to it -- this is based on what I most commonly see with the Select node, which seems to me to be the best analog to this scenario.

Given all of that, having the bars above and below the terminals as delineators seems unlikely to cause deflection in nearby wires... the nodes will already be moved apart. So if the black bars help readability (which, to my eyes, they do in PJM_JKI's latest post), I think that's a good tradeoff that won't, in practice, trigger wire kinks.

GregSands: The space is pretty tight. I'd rather not make that change. As long as true goes up and false goes down, such that the ordering is the same whether or not the user has enabled the bottom terminal, I think it'll work out. That's the same ordering, in inverse, as the Select node, so I think it is learnable.

PJM_JKI: You drew the inverted indexer on top. Why? I'd prefer that when the bottom term appears, it just augments the existing indexing, rather than flip the colors. Flipping the colors would imply that true had moved to the bottom. See image below.

Cy: Those are good questions. I don't think this discussion has made any evaluation of those thus far. We were just trying to get a syntax that was readable. Whether it augments or replaces is an open question, IMHO. Personally, I don't think inverting the colors is a good way to indicate "this is the false array", so I don't like using this for "just get me the false array". If we're going to add that feature, I'd do it by adding a Not circle to the ? terminal. *That* could be available regardless of mode. (But recall my earlier post that I'd rather not add a new way to do inversion... I think the existing "wire a Not" node" is a better solution because of readability, but I'm willing to go along if lots of people want to go this route.) See image below.

[NickNZ]

@CY - I don't think a clear spacer will work. VI analyzer should detect overlapping nodes on the structure - but they won't look overlapped! So black bars wins in my book. 

This thread is making progress refining this idea, but readability >> functionality with closely spaced tunnels.  

@AQ the Solid color fro the Conditional True was a refection of the T constant being mostly green and the F constant mostly white - See post above from PJM_JKI. on ‎08-17-2019 07:20 AM. I thought this was rather insightful. However this is not consistent with existing conditional tunnel. 

I am not very keen on the Not bubbles (had two bugs yesterday where I missed them!). There is lots about this on the forum and I think until there a suitable solution lets not introduce more opportunities for bugs and another place on the diagram to have to inspect for them. (As an EE I understand and relate to the bubble inversion logic - however LabVIEW is a programming language and not a logic diagram. ) 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Replace-the-Invert-Circles-in-Compound-Arithmetic-Nod...

So I am strongly against the inversion bubble on the conditional input and strongly support having the true indexer tunnel on top of the ? input, and the false indexer tunnel always below. 

[fabric]

The bool and the value are unlikely to arrive from the same originating node

That depends a great deal on both the programmer and the specific use case. However, even when the inputs do not originate from the same node it is often worth keeping them on a standard* spacing. (Isn't that one of the key tenets of NXG?)

I'm only pushing the point here because *if* the indexing terminal syntax is updated in any way it is probably going to be the last time, and I don't want to be stuck with a frustrating kink (think top terminals in Match Pattern) when the surrounding wires are all well-behaved. Borderline OCD? Perhaps, but IMO cleaner wiring enhances code readability, and that is something we all benefit from. 

(* Yes, I know LV many connector panes break from the 8px grid but we might as well make the new nodes good and proper!)

Given all of that, having the bars above and below the terminals as delineators seems unlikely to cause deflection in nearby wires...

I'm not at all concerned about the width of the delineator bars. They don't affect wiring.

[PJM_JKI]

@AristosQueue "You drew the inverted indexer on top. Why? I'd prefer that when the bottom term appears, it just augments the existing indexing..."

I see your point. It is a more logical evolution from the existing one. I personally dont mind much, but I can see use cases where this might be confusing (since I leverage the true/false constant semantic). 

For instance, if I look at the tunnel below, I would be tempted to think that the bottom one is True and the top one is False (but this would be incorrect).

[AristosQueue (NI)]

fabric wrote:

> it is often worth keeping them on a standard* spacing

...

> I'm not at all concerned about the width of the delineator bars.

My suggestion does keep the internal terminals on standard spacing. It's the space *between* tunnels that is being discussed. If you're not concerned with the delineator bars, then it doesn't affect you. 🙂

> That depends a great deal on both the programmer and the specific use case.

I don't believe it does. If you have a large directory of VIs... run a search (VI Analyzer test can do that) and tell me how often the data for indexing and the bool for conditional indexing come from the same node. I would like to hear your results. I found none in my small search (I didn't check the big archive that NI uses for a test bed). The closest I found was ones where the error wire passed through a Not terminal before being used as the conditional*.

* In case you're wondering, yes people have asked to let the error terminal wire directly. Discussions about that should be in the linked forum.

[AristosQueue (NI)]

PJM_JKI wrote:

> For instance, if I look at the tunnel below, I would be tempted to

> think that the bottom one is True and the top one is False (but this would be incorrect).

Not a parallel I ever would've drawn, but I see where you're coming from. It would be better if the term color style matched the T/F constant color style. But I do think that keeping the coloring of the "true" terminal consistent regardless of tunnel mode is more important because it is immediately proximal -- people will think the true terminal moved down if they enable split mode and the white background terminal moves, which is exactly what we do not want them to think.

• Possible response 1: "Well, we've reached a logical contradiction both ways so the feature cannot be done."
• Possible response 2: "Well, we could drive everyone nuts by inverting the coloring of the Bool constants and destroy productivity for years to come as people misread them."
• Possible response 3: "Well, we could invert the regular autoindexing tunnel. I think that would only bother people for a while."
• Possible response 4: "Consistency with the T/F constant is nice to have but not possible given the other ideals of the feature."

How bad is response 3?