Add Support for Array of Array

[SteveChandler]

In LabVIEW it is not possible to have an array of arrays. Something that gets you close is a 2D array but each row must be the same size. You can have an array of clusters of arrays to get around this limitation. Many languages do support arrays of arrays.

[Darin.K]

This already exists and the API has already been mangled! A string is an array of U8, an array of strings is an array of... you do the math. As we see we get two sub-pallets full of almost identical yet not interchangable functions. At the same time there are elements of arrays we'd like for strings and vice versa. Look for ideas on autoindexing strings or fixed size strings for example.

[SteenSchmidt]

@Darin.K: But don't you think a string is a common case worthy enough of its own abstraction on top of the underlying array? It would be trivial to make an 'Index String' primitive, but I'd expect the 'String Subset' to perform equally well in this use case, as that function surely is aware of the array structure of the string under the LV hood.

You can always convert to/from byte array and string with the built-in primitives if you want to change API on your string/array data.

I find the current string and array APIs quite natural and well balanced - not saying that new functions shouldn't be added. I just wouldn't want to introduce too much complexity into the APIs. In a perfect world the basic programmer shouldn't be forced to understand the underlying memory structure of each native data type. In that light an option to auto-index a string into or out of a loop structure would seem weird. The same programmer should just be grateful then, that the conversion from string to byte array can be performed really really fast at runtime, but does not have to understand why it is so.

Cheers,

Steen

[wiebe@CARYA]

I'm a bit late to the party, but I was thinking about posting this. Also, things did change the past decade...

I don't 'need' an array of arrays that often.  If it was an option, I'd use it more often though.

If I read this correct, Build Array and Auto Indexing outputs would need an option.

Build Array already has an option to switch between concatenate and add dimension. A 3rd option wouldn't be terrible.

Auto Indexing already has options (concatenate, indexing, last value). A 4th option wouldn't be terrible 

If anything mangles, it's having to index array, unbundle, index array, replace element, bundle, replace element. This could be index array, index array, replace element, replace element.

How would this simplify code? Well, like this:

(I know there's an increase array element vim.)

(I'm generous using IPES, it could be more messy)

[Intaris]

I concur. An array of arrays is not the same thing as a 2D array. Both should be supported independently of each other.

[Christina_R]

We've had this idea open to discussion for years, but I'm closing it now because the benefits of adding the "array of arrays" concept to G do not outweigh the costs of the increased array API complexity.

[wiebe@CARYA]

>because the benefits of adding the "array of arrays" concept to G do not outweigh the costs of the increased array API complexity.

At least 32 people don't agree.

Which API gets more complicated? Why would that cost much?

Why close the idea now it got some traction recently?

What's wrong with keeping it open to see where it goes?

Why? Why? Why?

[AristosQueue (NI)]

Array of array has been discussed many many times over the decades of LabVIEW. What follows is a rapid-fire data dump of why this idea is, in my opinion, not worth further discussion. My goal is not to be harsh, I’m just piling up reasons here so they’re all in one place for future reference. But the TL;DR is that R&D is tired of discussing an idea every time we review the exchange that none of us in those discussions sees as a likely change. 

1. You ask which API becomes more complicated? Every single one involving 2D arrays. We would need poly VIs and malleable VIs in a lot more places. But we would also be forever explaining why (for example) Transpose doesn’t work on array of arrays.  We would not have an obvious meaning to autoinddxing tunnels. Indeed, the array of arrays is arguably more consistent with the meaning of autoindexing tunnels, so there’s a likely point of confusion. 

2. The difference between a 2D array and an array of arrays is not, we have found, an intuitive concept to most of our users. There would need to be distinctive wire appearances, and I have not heard another way besides thickness to indicate rising dimensionality that is even vaguely intuitive. But it would need to be very distinct. 

3. The underlying data structure of an array of arrays is identical to the array of cluster of array. There wouldn’t be any memory advantage or performance advantage. The advantage of the cluster layer is purely notational that it clearly distinguishes what kind of structure is being manipulated. 

4. The upheaval of the language of introducing this now, with so many APIs not supporting it, and with array of cluster of array having no way to deprecate, means we would be creating polluting and non-inter operative APIs for no notable benefit (the notational disadvantages that lead to this idea even being proposed (we have to include bundle and unbundle nodes in our code) are advantages when looked at from code comprehension standpoint).

Conclusion. This idea is dead. It wasn’t even changed for NXG where our type system could have accommodated it. We’ve been over it and foresee no reason to reevaluate at any point in LabVIEW’s future. Thus the idea should be closed to signify end of discussion. 

[drjdpowell]

Question: what about the possibility of special handling of clusters containing only one element?  Allow array operations on clusters containing only a single array; the operation would apply to the contained array.  This would provide the code simplification desired for working with arrays of (cluster of) arrays.

[Intaris]

Responding to AQ:

1) I would be fine with transpose and other 2D array functions in general NOT WORKING with an array of arrays. Note: An Array of arrays is NOT a 2D array. I'm certainly not requesting this, this defeats the purpose of even having arrays of arrays. Just use a 2d array if you want this.

2) Are Maps and sets intuitive to most users? Are User Events intuitive? This is hardly a strong argument. There are lots of things in the software that are not intuitive to most users. I don't care.

3) Yes, precisely. This is all we want I think.

4) Why would we deprecate array of cluster of array?

I think, as usual, NI is not actually listening to what we want. I'll state it here for clarity.

An array of arrays is NOT a 2D array and 2D array functions should not work on them. OK? Clear? All we're asking is essentially for some syntactic sugar. Treat an array or arrays just like an array of anything else please.

[wiebe@CARYA]

@AQ

Thanks for elaborating on the reasoning.

1)

So the API is the main reason? The API doesn't need to change at all.

Only autoindexing out and build array would need an extra option.

As mentioned, an array of arrays wouldn't need anything more than an array of Booleans or an array of strings..

2)

My experience is different. Programmers from any other language are used to having arrays of arrays (or vector of vectors), and having a 2D array is much more unusual in other languages. 

Even you asked about it 25 years ago. 😂

To me, not having a array of arrays is one of those quirks of LabVIEW that we accepted. Because we had to.

3)

I don't care about the memory usage (, as it would be the same anyway 😋).

It's the added complexity and code bloat that you get when you work with arrays of clusters of arrays. I'm pretty sure that is the opposite of intuitive...

4) 

No notable benefit... Except for the programmers (the few that actually read the idea exchange) that gave the kudos.

>(the notational disadvantages that lead to this idea even being proposed (we have to include bundle and unbundle nodes in our code) are advantages when looked at from code comprehension standpoint).

Maybe if you're used to that notation. Few beginning LabVIEW programmer will find the (un)bundling comprehensive, even less if they come from C\C++.

I would prefer the bottom code:

It would also save front panel resources, as a cluster's border can't be 0 pixels.