LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
X.

User-friendly multidimensional array functions

Status: New

If there is one thing that tops my wish-list, that is a simple way to figure out the outcome of such simple actions as this:

 

ScreenHunter_004.jpg

 

Are the successive "Array" outputs going to be: {1, 2, 3} and {4, 5, 6} or {1,4}, {2,5} and {3,6} ?

I've been unable to find a good mnemonic to remember it.

So, each time I run into one of those, I've got to go through a debugging step. And since those functions are typically chained (say, convert an image into a 2D array, extract a sub-array, do some processing on it, replace the subarray, put back into image), this is a lot of debugging, which I have to repeat over and over again.

Don't get me wrong, debugging is not the issue. It is just that in language based environment, there would be no ambiguity as of which dimension of the array is read/written, because it is explicitly stated:

 

for (i=0; i<Nx; i++)

   for (j=0; j<Ny; j++)

       Array[i] = Input[i][j];

 

1D array functions are easy to interpret and use, but, at least to me, in higher dimensions troubles start with the simple "Index Array" function:

ScreenHunter_005.jpg

 

What's it going to be? {1,2,3} or {1,4}?

And if I want to access {2,5}, do I need to use this:

 

ScreenHunter_006.jpg

 

or that:

 

 ScreenHunter_007.jpg?

 

That may be just me (disclaimer: I can't seem to remember my left from my right), but I wished there was a more GRAPHICAL way to figure it out... I am not even starting to talk about more general N-dimensional arrays...

For 2D, here is my suggestion:

 

ScreenHunter_008.jpg, or to mirror the actual control behavior: ScreenHunter_009.jpg

Extensions to more dimensions could be looking something like:

 

 

ScreenHunter_010.jpg

 

and similarly for other array functions (I am just opening the Pandora box and running away).

Now, that does not really answer the question on how to figure out the outcome of my first example above... For this, I suggest (anathema!) to modify the auto-index design by offering an option to "expand" the auto-indexing icon and replace it with a larger, more explicit "function-like" icon:

 

ScreenHunter_013.jpg

 

Notice that, in my version of LabVIEW autoindex, you actually get a chance to choose which dimension is going to be auto-indexed. Of course that only works if know the dimension of the array beforehand, but that is most of the time the case.

Likewise for the autoindexing upon exiting a loop, although I am shying away from suggesting any design.

 

In summary, LabVIEW, which is supposed to be a graphical programming language, should offer better clues as of what some of the functions are doing. I have expressed my frustration with some of the array functions, but the same theme goes with others (such as strings! but then, LabVIEW is not a text-based language, so that would be unfair to try and compete with one).

 

My 2 cts.

 

6 Comments
AristosQueue (NI)
NI Employee (retired)

A neat idea. The size of a tunnel might be a turn off for some people (like icons for FPTerms -- there's a space vs information tradeoff), but I like the idea.

elset191
Active Participant

He mentions the ability to choose which dimension to index on.  That part has been suggested here.

 

As for icons for indexing tunnels:

test.PNG

 

Not sure what the icon would look like for say, index array. 

--
Tim Elsey
Certified LabVIEW Architect
X.
Trusted Enthusiast
Trusted Enthusiast

@ elset191: very true, I did not find that post in a quick search. However, I would argue that Ian's suggestion for the functionality is not answering the legibility issue I was addressing in my suggestion. As pointed out by Aristos Queue, not everybody might like a bulky expanded auto-index node (but this would be an option, so you LabVIEW geniuses would not have to worry about it Smiley Happy), but I would not mind myself, quite the contrary... In fact, the little number icon suggested by Ian would NOT help ME. The idea is to have consistency throughout functions and a little bit more "self-explanatoriness", if I may say.

As for your own suggestions, they have the merit of compactness, but they are, like Ian's icon, one level of abstraction above a full blown icon, and therefore need old brains like mine to provide an extra level of effort to interpret them (not mentioning eye strain). But definitely kudos for the creativity!

AristosQueue (NI)
NI Employee (retired)

> That part has been suggested here.

 

True, but let me stress, it is only a part of this idea. That one suggests allowing users to pick the dimension. This is a way of indicating which dimension is picked. Even if that idea was never implemented, I think this one has merit for the UI aspects. If only I could figure a way to pack the info into a terminal-sized space. 

donkdonk
Member

So I am not the only one who is unable to remember what is row and what is column...

If more dimensions are required, I always end up making a very small test vi to see which indez terminal does what..

 

That being said, I don't have a suggestion of how to cramp visual directions into s small icon.

CTF
Member
Member

+1 of those who can't remember how loops auto-index arrays.  And of course half the time the wrong dimension is autoindexed.

 

The ability to choose the dimension and and some sort of indicator of the dimension would save alot of small test vi's, debugging, and repeated transposing of arrays. 

 

For expediancy I often skip the autoindex and use the Index Array Vi where the tip strip tells me which dimension is indexed. Even something as minimal as the tip strip of the auto-indexed tunnel indicating the dimension (like on the Index Array Vi) would be a big help.