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.

[wiebe@CARYA]

Here's what I usually do when I need that:

The proposed idea is still less work.

The question remains: why is the output an OR? Why not an AND?

I'd be OK with both, as for now the output doesn't do anything while it could do something useful.

[dgdgomez]

It's a very good question, but cannot be both options?

[wiebe@CARYA]

That's what I said: "I'd be OK with both" 

Not what I mend at the time, but it seems useful.

However, AFAIK, it's already annoying that all tunnels move to make space when "conditional" is added to a tunnel. This new height will make it worse. Despite that I still like it.

[AristosQueue (NI)]

I think the physical space for different modes is too small to accommodate differentiating both And and Or operations. And I also don't think that Or or And either one is sufficiently intuitive for us to just pick one. So this feature -- in my opinion -- creates a readability issue for a very minor text improvement.

Rather than develop a tunnel specialization for this very specific Boolean operation, I'd rather a more general language suggestion of putting any node on the border of a loop and allowing it to accumulate values. Not entirely sure what it would look like, but, basically, drop an Or (or any other node) on the border of the loop, tag one input as implicitly shift registered, and then wire the other input (or inputs) from inside the loop. That would allow these Bool ops; it would also allow accumulating sums and products, filtrations of successive waveforms from a signal, and -- assuming the node in question can be any VI -- anything else users dream up. All we need is some notation that pins a node on the loop border in a way that doesn't look confusing.

We could have done the above in order to achieve accumulative indexing (drop a Build Array on the border), but we made a specialized tunnel for that because of its extreme commonality. But there's a law of diminishing returns for any particular operation -- how much R&D time is saving a couple nodes worth? I really don't think these kinds of Or and And ops are worth the dev time. BUT... the need for accumulating an open-ended set of operations does seem valuable, and making that notation easier seems valuable -- valuable enough to justify the R&D investment.

[GregSands]

AQ, my first thought was that your modification is an excellent suggestion.  But it's also fairly easy to handle any of these cases with a Shift Register or Feedback Node, so I wonder whether the development time would be worth it. One potential advantage might be combining with a Conditional Terminal, but again, that only saves a Case Structure.  I can't see much else that would be easily enabled, and configuring arbitrary nodes/VIs to sit in a Loop Border could be cumbersome.

[AristosQueue (NI)]

GregS: I agree. That's why I said "something like". I don't know where that balance point is to make this feature worth it.

[wiebe@CARYA]

@GregS: But it's also fairly easy to handle any of these cases with a Shift Register or Feedback Node

Same can be said for conditional tunnels. Or auto indexing. I like them both quite a lot...

Going form a tunnel to a shift register, adding a case and the desired "accumulation node" is something we all had to do a lot before conditional tunnels where there.

If this can be done in a more general way, it will save time. And be more readable.

[wiebe@CARYA]

 @AQ:

Any reason the SR input isn't on the left of the loop, like a normal SR? The init inside the loop seems a bit weird.

The shift (pun intended) from tunnel to shift register has consequences. The accumulator always needs the same type as input and output. A tunnel can have scalar input and array output. And we lose the conditional option...

Dropping a node would be convenient, but might not be sufficient.

You'd almost need a VI (or .vim) to support a flexible tunnel. So the .vi(m) could accept a scalar or array input, and have a scalar or array output. And an optional condition input. Then a loop could have the ability to put a "tunneling malleable" on the loop.

Then there could be a library of common accumulators, and custom accumulators could be added.

The malleable needs would to fulfill some criteria to be allegeable as accumulator of course. But the conditional for instance doesn't need to be a Boolean. Why not allow anything, for instance an error? Why not allow more then one input?

The only real requirement is the old accumulated value, and the new accumulated value. And maybe the input? The accumulation could be done on a FGV inside the .vim?

Of course, this only saves one SR. And we lost the init of that SR.

[AristosQueue (NI)]

> The shift (pun intended) from tunnel to shift register has consequences. The accumulator always needs the same type as input and output. A tunnel can have scalar input and array output. And we lose the conditional option...

False. I could have put Build Array in as my demo image. And there's no reason we couldn't still have the conditional terminal on the tunnel.

[wiebe@CARYA]

>> The shift (pun intended) from tunnel to shift register has consequences. The accumulator always needs the same type as input and output. A tunnel can have scalar input and array output. And we lose the conditional option...

>False. I could have put Build Array in as my demo image. And there's no reason we couldn't still have the conditional terminal on the tunnel.

My point was that your image showed a modified shift register. I'm not against shift registers with conditional terminals (that's another idea), but I think the image of the shift register is misleading, and that it should look like a tunnel. Then of course we'd want scalar to array, and conditional terminals. But the image shouldn't look like a shift register, but like a tunnel.