Rube Goldberg Code

[altenbach]

---

@Intaris wrote:

...when the elements in the cluster (which may have an origin beyond your control) has NO NAMES.

---

Or even worse, if multiple cluster elements have the same name. 😮

[Hooovahh]

Oh good one, and you reminded me another possible usage of the unbundle.  When there is over ever going to be one element EVER, and it is unnamed.

I've seen something like this done before, which allows for an array of an array without forcing all dimensions to have the same number of rows and columns.

[Intaris]

Array of clusters of arrays also allow for the data to be stored in non-contiguous memory blocks so even if they ARE all the same length, LV can allocate memory much differently.

[Darren]

---

@Hooovahh wrote:

I've seen something like this done before, which allows for an array of an array without forcing all dimensions to have the same number of rows and columns.

---

Here's a Darren's Nugget where I talk about using this trick to implement arrays of arrays.

[JackDunaway]

---

@PaulG. wrote:

I challenge anyone to give me an example where bundle and unbundle is better than bundle and unbundle by name.

---

Two idioms immediately come to mind:

1) The "burner" cluster used as a temporary manner of reordering elements in an array of objects/clusters in order to use `Sort 1D Array` on a sort other than the native cluster order

2) Fanning-out into a corresponding fan-in pane:

Other common uses include:

• bundling Event Registrations together prior to binding to the Event Structure
• bundling multiple channels before wiring to a Graph or Chart
• uses where it's desirable to inherit upstream data name rather than changing it (mostly involved with the naming of events, and operations involving reflection)
• ragged/jagged arrays

I would defend using unnamed/anonymous syntax in cases such as this when:

1. Scope is incredibly limited; the thought process of this syntax does not span across subdiagrams or VIs
2. It's more desirable to code defensively and/or concisely than verbosely for the sake of visual debugging -- the "show all elements by default" of this node (e.g., you cannot unbundle a single element of a multi-element object) makes it obvious when you accidentally skip an element that you intended to include, especially over the lifetime of that data structure as it evolves (this being a truly defensive practice is only partially true today, unfortunately. I wish that "Bundle" had the option to break the diagram for unwired elements. This would be helpful for, e.g., object construction. And for completeness, I wish the "Unbundle/Bundle by Name" also had the option to force fan-in/fan-out of all elements. For both these reasons, it's not truly defensive to rely on the auto fan-in/fan-out syntax of the Anonymous Bundlers, but it can be better than the Named Bundlers sometimes)

For the same reasons, I'll often intentionally not typedef cluster types, even those that cross subVI boundaries, for the explicit reason that it's desirable to break a diagram if the data structure mutates -- when scope is contained, and defensive programming is desirable.

(On the other hand -- I argue that Call Library Function Nodes and Property Nodes should *never* have "No Names"! Since, an anonymous parameter into a black box is not visually debuggable.)

[JW-JnJ]

---

@JackDunaway wrote:

1) The "burner" cluster used as a temporary manner of reordering elements in an array of objects/clusters in order to use `Sort 1D Array` on a sort other than the native cluster order

---

Awuuuuuuuh? This solves an age old problem that I've always been annnoyed that LabVIEW couldn't do elegantly. Sorting on some sort of "fitness function" (to borrow from GAs) or another value. Turns out I was wrong and it was cleverly hidden. Well I learned my new thing rather early today. Thank you.

[Hooovahh]

---

@JW-JnJ wrote:

Awuuuuuuuh? This solves an age old problem that I've always been annnoyed that LabVIEW couldn't do elegantly.

---

Oh yeah OpenG array tools use this technique for the sorting but keep the sorted pointers.  This is obviously handy if you have to arrays that are linked some how, and rearranging one by sorting, means you should reorder another array in the same way (OpenG also has the reorder array function).

[JW-JnJ]

---

@Hooovahh wrote:

---

@JW-JnJ wrote:

Awuuuuuuuh? This solves an age old problem that I've always been annnoyed that LabVIEW couldn't do elegantly.

---

Oh yeah OpenG array tools use this technique for the sorting but keep the sorted pointers.  This is obviously handy if you have to arrays that are linked some how, and rearranging one by sorting, means you should reorder another array in the same way (OpenG also has the reorder array function).

---

Pardon my challenging on a topic I just learned about this morning.

Wouldn't it be better to just bundle all of the objects you want sorted in with the initial cluster?

(asking because if I'm wrong, there is a VERY good answer in there)

[crossrulz]

I have had many situations, especially with lookup tables, where it was better to have seperate arrays than to have an array of clusters.

Also, you have to be very careful with the sort.  It sorts on the first item in the cluster first.  So you have to make sure your cluster is in the order you want it to be in.

[JW-JnJ]

---

@crossrulz wrote:

I have had many situations, especially with lookup tables, where it was better to have seperate arrays than to have an array of clusters.

---

Ahh, so more of an architecture driven choice than a computation one. Makes sense.

Speaking of which, it seems there is negligable computation difference after I ran both through a timing test.