What is your goal with this suggestion? I'd like to know why you want this because your proposed solution seems to have a lot of problems as currently proposed. Maybe there's an alternative that addresses what you're trying to fix.
The current problems I see:
A) What happens when you have longer integers or a long list of short integers? The node becomes severely distorted, with a list taking up valuable horizontal space instead of the relatively cheap vertical space that such a list would use today. (Vertical nodes tend to cause less problems for readability in LV than horizontal nodes.)
B) How do you tell that is the Index Array node when the icon is totally obscured? I do not know what that node is as it stands... looks a lot like a comment.
C) What is the justification for doing this to the Index Array node and not not all other nodes? Anything I can imagine as a reason for doing this would seem to apply to all nodes. I don't see anything making this one special. For example:
(I made the triangle large to accomodate a longer numeric value and to still be able to show the Add glyph, kind of to make a point about the visual issues I see this creating.)
All in all, I'm not seeing much advantage here and I'm seeing a whole lot of downside. So tell me why... maybe there's an alternative.
The goal should be obvious from the title, namely compactness.
A) Long numbers would take up no more space than they do anywhere else.
B) You can tell it's a an Array Index node by the brackets on the left & right sides. The icon is not "totally obscured". It does not look like a comment; look at the comments in this image I posted, their appearance is quite distinct.
C) The justification for doing this is that indexing by constants is fairly common.
As for your example, the Expression Node handles that:
When I want to add a constant to a value, I use the Expression Node instead of an Add node and a constant, for compactness.
One note about your example is that it only has a single output connector, whereas the current index array node can handle multiple output connectors by simply growing it down. Thus if I want the first 4 items, I just need to drop the single index array, grow it to 4 inputs, and voila, the first four items, or attach constants to the inputs and the specific inputs are there.
My (admittedly minor) irk about the index array is that it doesn't have an array out connector like other array items (Kind of makes sense, it doesn't alter the array), and the VI analyzer gives a hit if you put the index array inline with the array wire since it sees the array wire as being 'behind' the index array icon. It would be nice if the VI analyzer would ignore the array wire connected to the index input for the hidden wire check.
Did you miss the last 3 words of the subject line?
another possible area of concern, arrays of larger than 2 dimensions, it can be hard to see an error in the 'element' part of the node when you want a subarray of a part of a 3D+ array. In the pull down version, you can see quickly which dimension isn't wired, but looking at an expression style array it is much harder to see. In example, I have a 4D array and want the subarray consisting of the 3rd dimension of the 4th first index, 1st second index, and 3rd 4th index. The pull down you can see quickly if the 3rd index is wired, but it is less obvious to catch when it is [4,1,,3]. It would be easy to misstake [4,,1,3] as the above for instance.
I'd like this idea...extended.
It's kind of like a mini MathScript node and adresses a major issue of array primitives (and their icons) which is that they are absolutely cryptic.
I, like others, had proposed modifications in the past, but I think this could address a lot of these problems... provided you allow additional inputs to enable things such as (i: j), or (:,i), etc.
Maybe something like the original icon (which can be expanded) but with one state where there is no other input beside the array itself (for cases illustrated in the OP)? The naming convention for the variables would have to be discussed, but the alphabet comes to mind.
I will admit that I did miss that part of the subject line. With that said, I still think it would not really gain anything and would make things less readable.
Did you miss the 3rd word of the subject line? You would gain compactness.
No I did not miss the 3rd word, I don't think you would gain much in the way of compactness, and the loss of readability would be a larger problem than what little compactness you would gain.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.