Tunnel Mode Conditional ... output condition

[dgdgomez]

The idea is to know the result of the tunnel mode condition, in this case, it is to know if any element has been indexed.

This publication is motivated from the following discussion: Tunnel Mode Conditional .... output condition (by @ouadji)

Regards.

[crossrulz]

Considering the code AristoQueue's notation would replace, a shift register like notation actually makes more sense.  After all, you are just acting on the value from the previous iteration and then any new data to add, process, etc.

[wiebe@CARYA]

I agree that acting on previous value makes it look more like a shift register.

But when that shift register get's conditional action, and can have scalar in\array out, for me it starts looking more like a tunnel.

I don't really care what it looks like. But it would be useful if there is conditional and scalar to array options. Like a tunnel . AQ's (very preliminary) made me think it would not.

[AristosQueue (NI)]

> I don't really care what it looks like.

Let me make that terminal 100x100 px and blinking ... we'll see how long that attitude lasts! 🙂 Ok... seriously... the appearance is most of what matters in any feature like this.

There are three types of features to help write LabVIEW code:

a) Feature to express a new concept that the language has never encapsulated before.

b) Feature in the editor to generate existing code concepts faster. That can be as simple as autorouting wires to generate a wire path or as complex as the project template wizards that script an entire new project into existence.

c) Feature to render an existing language concept in a new way that is more compact and more mentally accessible. These features are the syntactic sugar.

This one is type (c). There's nothing this new tunnel concept enables that isn't already easily possible in LabVIEW, so the whole goal is to make something that is faster to write and easier to read (aka "more maintainable"). Appearance drives that.

[wiebe@CARYA]

@AQ:

Agreed.

The "correct" look depends on the way you look at it:

Is it a shift register with tunnel features?

Or a tunnel with shift register features?

Obviously it does matter somewhat how it looks. Biggest problem with NXG is how it (and the code) looks .

I was trying to convey that I don't care if it looks like a tunnel++ or a shift register++.

[AristosQueue (NI)]

Weibe: understood.

I got to thinking about this feature some more...

Steps today:

1. Create new shift register.
2. Create initial constant value.
3. Drop the aggregating node.
4. Wire LSR (left shift register) to the node.
5. Wire node to RSR.
6. Wire in the other value(s) of the node.

So for this feature to be worth doing, it would need to be possible to write the behavior with less work than that. But what I've proposed above works out like this:

1. Right-click to create new, special "node hosting" tunnel on loop.
2. Drop new node on tunnel.
3. Select which input terminal of the node pairs with the LSR.
4. [???] Do something to set the LSR initial value or hope that the default value is always right to start the aggregation.
5. Wire in the other value(s) of the node.

That isn't really a lot of savings. And for "And", the default value of FALSE isn't the correct initial LSR value (you need to start with TRUE and then And in all the successive values). So that's a trivial desired use case that demands that item #4 be solved.

So, as proposed, it wouldn't be an improvement over what we have today, and it might well be worse -- definitely worse when we consider readability, where we would have introduced an alternate syntax that does the same thing as a known syntax without any advantage to the code writer.

But if we look at those steps above, if we could do the once for a given node (i.e. say "this is how And behaves when dropped inside the special tunnel"), then we could see real savings -- it could be as simple as:

1. Right-click on loop to create special tunnel for a specific node (i.e. And)
2. Wire in the other value(s) of the node.

So... how does that get encapsulated? We need a document that says, "This is the core node, here's the special input terminal, and here's its initial input value." Those documents are source code that the caller VI would link to. If they're going to be source code, that makes me ask, "Can I encode this as a specialized VI?" because it is way easier to make a specialized VI type play well with the system than to introduce another source file type entirely different from both VIs and libraries (VIs come with debugging available, they're known to appbuilder, they can be scripted, etc). These would be VIs that would be marked special as "I define a loop tunnel behavior", so they couldn't be dropped as regular subVI calls.

Can anyone propose what such a VI might look like that would define the parts the tunnel would need?

[wiebe@CARYA]

I agree that there's not much gain on creation. When a "conditional" option is added, it will save a bit more though.

There could be other benefits. A node on the loop could be easier to maintain when the loop resizes.

Not sure if  to readability get worse or better.

As for the LSR value, this could simply be on the left side of the loop like a normal SR? So it will be exactly like a normal SR, except that there's an option for node selection.

>Can anyone propose what such a VI might look like that would define the parts the tunnel would need?

If we can\must define VIs, the savings will be even less (pretty much nothing):

Maybe we should step back to the original idea (?):

The conditional terminal has no output. If it returned an OR or AND of the values, it would at least do something useful.

[AristosQueue (NI)]

> If we can\must define VIs, the savings will be even less (pretty much nothing):

Anyone ever tell you that you don't dream broad enough? 🙂 Work with me here.

You define the wrapper once for a given operation, so now you have:

Or whatever you want to build. And that allows this to be easily written:

The tunnel glyphs presumably come from the icon of the wrapper VI.

Conditional is enablable on any of the tunnels -- that's a trivial code gen.

So now we can build And, Or, Sum, Product trivially. With some thought, we could make the tunnel wrapper VI stateful and implement an Average Value tunnel.

Unpacking on the input side should also be considered -- create a class that represents a set of things and the class could define a tunnel operation to automatically to indexing into the data. It's the same principle as the outputs -- a shift register'd state for where in the iteration and an output value.

[AristosQueue (NI)]

The "Add Custom Tunnel" pull right needs a "Browse..." option for picking others off of disk. I assume it would pre-populate like custom probes from some set of directories plus any custom tunnel definition VIs included in the project or already in use in the hierarchy elsewhere.

"custom tunnel definition VI" is a terrible name... let's go with "XTunnel VI" for now. Far simpler than an XNode -- I think these can be entirely defined in a single VI.

[AristosQueue (NI)]

Now, keep in mind, this really is syntactic sugar -- consider that you could just write this today:

That & node calls a preallocated reentrant VI that has an uninitialized shift-register on its block diagram. It would be something like "point-by-point And" if we added it to the palettes today.

We could do this. But it is rare (in my observation) for any of us -- novices or experts -- to write G code this way. Why? I think it's that need for the reset terminal that makes us reluctant to build such point-by-point subVIs. Placing the subVI on the loop boundary eliminates the need for caller to worry about that behavior.

[wiebe@CARYA]

Did you just came to the same conclusion? As long as you make that VI, it doesn't really save much to have it automatically inserted on the loop on creation.

I think this could increases readability. It would prevent wires going from left to the right. A few of those wires can in practice confuse things. With this feature, you only have to worry about what is on the right, while now you have to look to the left and right covering the middle as well.

As for defining an interface for such a VI (because it would be neat)...

Does it need exactly 1 input? Usually, but why enforce it?

Does it need exactly 1 output? Usually, but why enforce it?

Does there need to be an iterator or init input? Usually, but why enforce it?

Could there be a conditional input? Sure, but how is this different from the oter input(s)?

If there is an iterator\init input, it should be recognizable by LabVIEW. Just so we don't have to (remember to) wire it.

The rest could be a normal VI(M), with 0..n inputs and 0..n outputs. Inputs should be forced on the left, outputs on the right, though.

Ideally, one of the inputs could even be a class wire, enabling dynamic dispatchable tunnel behavior per iteration. But that could be difficult, as the VI has state, and should probably be reentrant. So a DD input is probably off. The VI itself might need to be static and reentrant, so it can keep state. It's subVI's could still DD however, defining behaviour of the static VI.