simplify array by removing duplicates

[JÞB]

---

@altenbach wrote:

---

@JÞB wrote:

---

I had always assumed the the number of auto-indexing input tunnels into a Loop did not affect performance

---

I was thinking more about code readability. There is probably no difference in performance. (of course LabVIEW probably needs to check all the array sizes and pick the shortest to determine the number of iterations, but that's peanuts. :D)

---

So you used bundle and unbundle without name?  Its only 11:00 PM here.  You older guys need to get some sleep!

Oh, how many emojis! 

[altenbach]

---

@JÞB wrote:

---

So you used bundle and unbundle without name?

---

Sometimes the elements have no name, and naming them would add more code 😄

[jwscs]

altenbach wrote:

"""

He also has twice the number of auto-indexing input tunnels on the loop. One is enough. 😄

"""

what kind of costs do auto-indexes have? i assumed that would be an O(1) operation,

bc the header part of the array-data-structure holds the length information.

[jwscs]

jeff wrote:

You older guys need to get some sleep!

nice one .. i am not sooo old not even 40.. and you were right .. it was already past 03:00 for me (AM for you guys with only 12hours)

[altenbach]

---

@jwscs wrote:

what kind of costs do auto-indexes have? i assumed that would be an O(1) operation,

bc the header part of the array-data-structure holds the length information.

---

Dirt cheap, but I already commented here. I was more worried about all the extra array allocations but have not done any benchmarks (and probably won't :D)

(Basically, for each iteration we need to operate on two array elements of a 2D array that are adjacent in memory (well, strings are a bit different, but let's consider the general case). It does not seem right to first deinterlace that data structure into two separate 1D arrays (new memory allocation) scan one for numbers into a integer array (another new memory allocation), just to use them again pairwise inside the loop.)

(I am on the west coast, so I can stay up a little longer :D)

[JÞB]

---

@altenbach wrote:

---

(Basically, for each iteration we need to operate on two array elements of a 2D array that are adjacent in memory (well, strings are a bit different, but let's consider the general case). It does not seem right to first deinterlace that data structure into two separate 1D arrays (new memory allocation) scan one for numbers into a integer array (another new memory allocation), just to use them again pairwise inside the loop.)

(I am on the west coast, so I can stay up a little longer :D)

---

Lesson taken Thanks- I had not thought it down that far.  I love how much I can learn by just asking questions!

Spoiler

In my own defense, I'm running on a couple of busted ribs.  It can get distracting.

[altenbach]

---

@JÞB wrote:

---

Lesson taken Thanks- I had not thought it down that far.

---

The thing is that the compiler does a lot of magic behind the scenes and sometimes the way things are connected on the diagram might be dramatically different when transformed to the final machine code. (details). My comments are just based on gut feelings. Only careful benchmarks would tell.

OTOH, computers are so fast that we don't really need to worry unless the data structures are gigantic. 😄