Expandable output shift registers

[SteenSchmidt]

Hi,

When I have some complex operation to perform on a number of input data I often use a loop to avoid duplicating code of course - for instance:

Sometimes, when the number of input data is small (like 2 or 3 elements maybe), I skip building the loop output into an array just to index it out again outside the loop. Instead I do something like this (mis)using a shift register:

As a simpler alternative I suggest output shift registers be expandable just as input shift registers are:

For a small N-count this could generally be used instead of indexing an output auto-tunnel.

Cheers,

Steen

[AristosQueue (NI)]

Not sure what I think of the idea, but the pattern you show in your second image is one I haven't seen before. Elegant notation for small sets.

[Intaris]

Hmm, I've never needed something like this but it certainly has an aesthetic appeal to it.

Big Q: Do the output terminals accept wiring from within the loop?

[SteenSchmidt]

@Intaris:

I think the output terminals should accept wiring from the inside, but I'm not 100% sure? My argument is that it then would be possible to present a default (or early-stop) value to register positions not yet iterated to, in case you stop the loop early. There are possible drawbacks and pitfalls with this too though, thus my hesitation...

/Steen

[Intaris]

Well my question is based on there being two incompatible ways you could do that.

1) Replacing results from previous iterations

2) providing default values

I don't know if either is a good idea but they look like shift registers, so they look like they can be wired to.....

If they were offset to the outside of the loop on the other hand (with the wired terminal being inside) it would be clear that they CANNOT be written to which I think would be visually more clear to understand.

[SteenSchmidt]

So we basically have these two options then:

I'm more in favor of A. Mostly because all shift registers then have the same terminals as expected, but also because one could think of algorithms where you'd want to alter i-1, i-2 etc. outputs at the last moment just before you exit the loop, if some condition materializes.

So even though B also lets you set startup values for i-1, i-2 etc., it's less flexible.

BTW notice how the above really just looks like a bunch of separate shift register, instead of what it is, namely several iterations of one shift register? I (obviously) think this makes that point more clear:

/Steen

[tst]

The main appeal of this idea is that it negates the need for the array, but I think the reversal of the order of the elements is confusing enough (as you pointed out yourself in the other idea) that I wouldn't ever want to see something like this.

On a somewhat related note,

---

@AristosQueue (NI) wrote:

Not sure what I think of the idea, but the pattern you show in your second image is one I haven't seen before. Elegant notation for small sets.

---

While I haven't seen the pattern before either, I'm surprised you would consider it elegant. It takes up more BD space than the index primitive, it's much harder to understand and it really messes up the order of the elements. It may be more efficient, but I wouldn't want to run into code like that either.

[SteenSchmidt]

@tst:

The reversal of the order isn't any worse than stacked input shift registers. Regarding the pattern, here is a real-world example:

At the red arrow and thereabouts; The two wires exiting the For-loop are two very large 1D-arrays of strings both just ending in indicators to the far right on the BD. Had I instead used a Build Array inside the For-loop, and an Index Array outside the For-loop, I would be facing these changes against my current pattern:

1) The intermediate 2D-array of strings would mean at least one additional data copy of the entire data set.

2) The two 1D string arrays aren't of the same length, making it necessary to embed each 1D-array in a cluster before building the 2D-array, and vice verse on the other side.

3) The BD would be at least 120 pixels wider while exactly 12 pixels lower. That's actually 4% larger (BD area-wise) than the current implementation.

4) I don't care about the order in which the two wires leave the For-loop, there is adequate documentation for this to not be of any concern.

5) If stacked output shift registers existed in LabVIEW I would actually save BD space as well as memory footprint: my BD would be the same width as now but 12 pixels lower, resulting in a net BD area decrease of about 2.5%

/Steen

[Intaris]

For an application which may need it there is a c lear benefit on outputting a static number of iteration results over outputting all and then selecting the interesting part.

The question is if THIS method is good enough to make it into the language.  I'm still torn, I feel it's too unclear at the moment what's going on.  I feel there's more visual indication needed to make it clear what the shift registers ont he right are doing different to "normal" shift registers.

[SteenSchmidt]

I can see I was too quick with my cutting and pasting before (the arrows in the right hand shift registers point in the wrong direction ).

Anyways, I can spot a confusion within my suggested right-hand stacked shift registers in as they would potentially make the same data available on the left and right border of the loop structure in the same cycle. That makes the right-hand stacked shift registers merely a shortcut for pulling a wire across the loop structure. Albeit irritating to have a wire across the structure, it beats by a mile hiding dataflow by not having that wire.

Realizing this actually makes me hate the idea now . So go ahead and decline it!

Cheers,

Steen

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.