Allow to name array indexes

[MimiKLM]

Hi,

As in the subject.

Now when you create an array the indexes of the array can be only labeled as the static comment field. There is not any build-in label/handler which could be used. Current situation looks like that:

It would be better for readibility if developers could name the indexes and use it later on.

Picture represents the idea only, whole point is the description shoud be a build in handlers.

Now LV names first four indexes (when you hover over on it) as column, row, page, vol; later on are only dim 5, dim 6 and so on.

I believe if would increase readibility and save coding and debugging time.

[Intaris]

AQ.

Well if you transpose a 2D array the second dimension is autoindexed.....

[MimiKLM]

Intaris, point is not to do other thigs just because change the dimention you want to autoindex.

Generally, it looks like there is something to do in the area of accessing & naming the array dimentions.

[AristosQueue (NI)]

Intaris wrote:

> Well if you transpose a 2D array the second dimension is autoindexed.....

Really?! That surprises me. How would the downstream For Loop even know that the array had been transposed?

[later]

I went and tested... no... even after transpose, we index the first dimension. I don't know of any setup in which the loop indexes any other dimensions other than the first.

[crossrulz]

AQ, I think you misunderstood Intaris.  If you transpose, then the second dimension of the original array is indexed.  In other words, you transpose so that the correct dimension is indexed.

[AristosQueue (NI)]

Crossrulz: Ah. I see. Thanks for clarifying.

[altenbach]

I still don't get it. You are talking about some metadata that is carried along the multidimensional array wire and magically adapts all array primitives it touches. Should it propagate to the front panel (e.g. via tip strip when hovering over an index terminal of an array control)? Should it be reflected in the context help? If you add two arrays with different dimension naming, should it break the wires or add coercion dots? Could you clarify how all this should be implemented?

[AristosQueue (NI)]

Altenbach:

I gave this some thought over the weekend. It would, I think, work basically just like names of cluster elements.

With a cluster type, you have the names of the elements in the type, so when you create indicators/constants/controls, the names do appear on the panel. Even if the labels are hidden, those names are available as part of the panel object if it gets copied/pasted elsewhere.

The names would propagate as part of the type. Some few operations would need to be aware of them: if you went through Transpose Matrix, we'd flip the names, for example. I doubt that we would add another input to Build Array (the non-concatenating version) to provide a way to set the names, but I can easily see a name manipulation primitive that lets you read/write the names of different dimensions.

Prims like Index Array would name their terminals accordingly.

Then when you hit an Index Tunnel, the inner wire would take the name of the NEXT dimension to be indexed. So if you had rows named Students and columns named Grades, and you autoindexed that 2D array, your inner wire would be named "Grades" because that's what you'd have -- for each student (row), the grades for that student.

There's a problem with plural vs. singular names. You will want to give the dimensions singular names so that the names on the terminals of Index Array are singular (i.e. "Student" and "Grade"). But you'll want to name them plural so that the autoindexing of internal names is a set (i.e. "Grades"). What that probably means is that we'd end up encouraging you to use singular names and then use a punctuation decoration to indicate a set of them... so Index Array would have a terminal named "Grade" and the inner wire would have a name of "[Grade]". But that's just a first thought off the top of my head on that problem... there may be something more elegant ("Grade array" maybe, but that maybe doesn't localize well for non-English), or we might include a way to include both names (i.e., when you supply the name, there's a way to type in both the singular and plural). Or we might decide to ditch English altogether and get a language that has a standardized way to establish plurality. Wouldn't that be lovely?

Regardless of the naming thing... the weight on arrays is negligible -- it's all carried in the data type, not in the runtime data, so it doesn't even exist in the runtime engine if it isn't needed by the code (just like names of clusters can be dropped out today).

The request is viable. Despite the thought I may have put into it, I wouldn't see it happening anytime soon without a lot more groundswell of support, but at some point in the future when the type system gets its next overhaul (currently slated for 2019, subject to change), I think it would be worth factoring into LabVIEW as a useful but not critical aid to programming.

[GregSands]

As someone currently working with true 4D arrays, I like this idea!  Especially being able to index one dimension out of the array, and retain the other names, rather than "row" and "col" now referring to different dimensions than they did originally.