Add "index past replacement" output(s) to "replace array subset".

[altenbach]

After applying my own subjective intellisense (see also ;)), I noticed that "replace array subset" is almost invariably followed by a calculation of the "index past replacement". Most of the time this index is kept in a shift register for efficient in-place algorithm implementations (see example at the bottom of the picture copied from here).

I suggest new additional output terminals for "replace array subset". The new output should be aligned with the corresponding index input and outputs the "index past replacement" value. This would eliminate the need for external calculation of this typically needed value and would also eliminate the need for "wire tunneling" as in the example in the bottom right. (sure we can wire around as in the top right examples, but this is one of the cases where I always hide the wire to keep things aligned with the shift register).

If course the idea needs to be extended for multidimensional arrays. I am sure if can be all made consistent and intuitive. There should be no performance impact, because the compiler can remove the extra code if the new output is not wired.

Several String functions have an "offset past ..." output (e.g. "search and replace string", "match pattern", etc.) and I suggest to re-use the same glyph on the icon.

Here is how it could look like (left) after implementing the idea. equivalent legacy code is shown on the right.

Idea Summary: "Replace array subset" should have new outputs, one for each index input, that provides the "index past replacement" position.

[altenbach]

Not sure if it should be called "index past replacement" or "offset past replacement". The idea uses both interchangeably.

Maybe it should be "offset" for strings and "index" for arrays. I am sure we can come to a consensus. 😉

[crossrulz]

A couple of random thoughts:

What if you use a negative number for the index?  This happens to me all the time as I am using this function with Search 1D Array.  If the item isn't found, it isn't replaced.

What if you replace the last item in the array?  Should the output index be -1?

I still like the idea, but it needs just a little more thought to some of the situations like these.

[altenbach]

I think it should just blindly increment whatever is wired to the index, no need for exceptions. Nobody is forced to even use the new output.

[Manzolli]

Couple thoughts:

1) If the “offset past replacement” or “index past replacement” gets out of bounds, it should be changed to “-1”?

2) In multidimensional arrays, how the increment would work across the dimensions? Increment only one dimension (size defined by correspondent subarray dimension) until it reaches the end, then increment the next dimension once (size defined by correspondent subarray dimension), back incrementing the first dimension until it reaches the end again, and so forth?

[altenbach]

> If the “offset past replacement” or “index past replacement” gets out of bounds, it should be changed to “-1”?

I am still not sure about the "out of bounds case". Either "-1" or blindly apply the math shown in the equivalent legacy code. Arguments?

> In multidimensional arrays ...

All the dimensions are orthogonal and can be treated the same way. It should increment all index terminals that are wired and should behave identically as described for the 1D case above. There will not be anything different or unusual for the multidimensional case.

See also my comment here. Not everybody seems to be familiar with all working replacement modes. 😉

Unwired indices should not have a corresponding output, only the ones that are actually wired.

[johnsold]

Good idea.

While I have not thought through the corner case issues, this would be a big productivity boost for most users of Replace... Regardless of the final decision, make sure that it is thoroughly documented in the help.

My preference would be for Index past Replacement. I do not tend to think in terms of "offset" for arrays.

Lynn

[heel]

This is a great idea.

But it applies equally well or even more to the (get) Array Subset VI.

When parsing arrays you often have to extract from consecutive portions. For this the "Next Element" would be very handy. An example use case is shown below.

Note that the drawing of a neat layout using the legacy method is surprisingly difficult having crossing wires and wires going backwards.

[RavensFan]

Don't claim that having backwards wires in the legacy code makes the new idea better.  Both examples you show have backwards wires, and both can be drawn so that you don't have backwards wires.

[JÞB]

Might as well add it to threshold 1D Array as well.  since this is so common

The glyph for the new terminal would need some work  (Bar over x / bar under x comes to mind)

Kudos!

[AristosQueue (NI)]

I am not opposed to this idea, but I do notice something about heel's post... in the legacy code version, those subset operations proceed in parallel. In the modified version, they're serialized. You're reducing significantly the compiler's opportunity for optimization (depending upon what is downstream) by combining funcitons and creating a data dependency where none existed previously. Now, Array Subset is a very low intensity operation most of the time because it just creates a reference into the existing array, but there are times when the copy required dots will drift upstream from some other optimization such that Array Subset actually copies the contents of the array. That means your serialization will have performance impact on the parallel operations that may not need to make a data copy.

It's something to keep in mind when asking for these secondary outputs from any node. I've toyed with the idea of creating nodes that are somehow "linked" such that they drop as a pair, move around on the screen as a pair, but do not create the same data dependency so that downstream code waiting on one output isn't forced to wait on the other output. It would be a sort of "split node" notation. I haven't found any syntax that I like enough to post as an idea... but it is ideas like this one that make it keep coming up in my notebooks.