Allow access to subarray from array of cluster elements by array and dot notation

[jlokanis]

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

 

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported.  For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

 

[jlokanis]

Actually that is more depressing than surprising.  My LabVIEW skills have benefitted greatly from exposure to other languages.

Regarding your other point, I agree that using standard LV conventions would be best in this case.  But I would then argue that the standard LV convention for an array is the use of the C convention [ ]. There are many examples of this throughout the low level LV functions and the property nodes:

 

In fact, it appears that the standard for all property nodes is to indicate clusters and arrays using the same notation as C uses for structures and arrays.

So, using the [ ] in the unbundle would be very consistent with current LV practices.

My question now is will this also improve execution speed?  Can the compiler better optimize the code with this method of indicating a sub array from an array of clusters?  And how soon can you get that coded up and released?  🙂

-John 

[JackDunaway]

---

jlokanis wrote:

So, using the [ ] in the unbundle would be very consistent with current LV practices.

My question now is will this also improve execution speed?

---

Of course! The [] notation will improve execution speed over Aristos' less efficient glyph notation.

Haha, well, all joking aside, I still LOVE your idea, and actually prefer the [] notation AS A glyph (see below!). As you have very well pointed out, it maintains the standard that LabVIEW has already carved in stone. Good job finding all those!

To NI R&D: even if it does not improve execution speed (which it should actually be able to), I Kudos this idea based on increased BD readability.

Finally, although I have a broad (but shallow) exposure to other languages, I am in Aristos' 70% group.

[rolfk]

The performance argument most likely does not cut it here. LabVIEW would have to create a rather complicated form of sub arrays (a special internal array datatype that can represent various types of arrays in order to improve performance. For instance transposing a 2D array will create a subarray datatype that points to the original array data and stores some sort of flag that the array is transposed. Array functions do often have special code to deal with such subarrays directly: The index array function for instance would for a transposed subarray simply switch the index inputs before accessing the original array.)

Also such a complicated subarray datatype would only make a difference in array operations performance if that operation has explicit code to deal with this subarray flavor. Any array operation not supporting a specific subarray flavor will invoke a method to translate the subarray into a regular array to work on it in the normal way.

Message Edited by rolfk on 07-09-2009 09:21 AM

[Intaris]

And another user finds out that there can be multiple pages of comments the hard way..... 🙂

I thought I read somewhere recently that LV already has some flags internally for Arrays such as Reversing them, transposing them and so on.  I think it was in the Thread about a more advanced Sort algorithm for Arrays.....

Assuming that LV is Object oriented internally, wouldn't the new data type objects have the methods themselves instead of relying on the primitives to cover each and every datatype themselves?  Is it not feasible that adding a new data type object would simply bring all the required methods with it?

[Intaris]

I just realised that my last post contained some self-contradictory ideas.  I fear the OO ideas I was mentioning are far from reality......

[jlokanis]

Maybe I am misunderstanding your comment, but I think your argument that the speed would not improve revolves around the subarray access being 'inplace' thus allowing array operations on the subarray to affect the source array.  That is not my intention.  I expect that accessing the subarray would involve a copy of the data and memory allocation.

I am simply stating that if the copy was done by some low level ASM code instead of processing a for loop on the block diagram with an auto-index tunnel, that it might (should?) be faster.

In any event, it would make the block diagram cleaner and that is reason enought to do this. 

[yledieu]

I often use Cluster Arrays and i dream of having this functionnality.

Please implement it !

[kennymolc]

Of course as I attempted to suggest the same idea, I found it's already existing ... Kudos to you.  Here was my graphical interpretation of the issue

[GregSands]

I've created an XNode implementation of this idea - it's certainly feasible!

[Jason_Harrigan]

This is a great suggestion. I like the auto-index glifs, but I'd just get rid of the black arrow and replace it with a auto-index glif.