Swap Vector Element function

[dadreamer]

Playing with Scripting VIs I have found this Swap Vector Element node:

I wonder, how safe and stable it is and why it's not included in all LabVIEW releases along with other array functions?.. It may be useful sometimes because it returns old element value which is replaced by new one. Replace Array Subset is not able to do that.

[GerdW]

Hi dadreamer,

where did you found this? Which LabVIEW version?

When I search with QuickDrop for "Swap" I only get two functions from BLAS library…

[dadreamer]

GerdW

Open an example Adding Objects.vi, located at C:\Program Files (x86)\National Instruments\LabVIEW 2013\examples\Application Control\VI Scripting\Creating Objects, change Ring constant "Subtract" to "Swap Vector Element" and execute the VI. Or you can look at the attached file. I believe it's not matter which LV version I have. This instrument exists on any version starting with 8.0.

[GerdW]

Hi dadreamer,

thanks.

I also found this function on LAVA meanwhile, with two more "interesting" ones…

[dadreamer]

To be completely correct, this VI is presented in LabVIEW beginning with 7.0 version. Its description slightly differs from the one of new LVs:

I cannot find any signs of instability, but still ain't sure if it might be used in my own projects.

[Bob_Schor]

That's really weird -- there's a function, "Swap Vector Element", that doesn't exist in the regular Function Palettes, that doesn't have Detailed Help in the LabVIEW Help, and that you can only create by executing a Script to "create a function called Swap Vector Element"?  What in Blazes is going on here?  Knowing this has been "somewhere" since LabVIEW 7.0 doesn't make me feel any more confident about it ...

Bob Schor

[tst]

---

@Bob_Schor wrote:

What in Blazes is going on here?

---

There are a number of primitives which NI has created, but never made it to the palettes and at least some of them can be seen in the list that the creation primitive accepts. These are things like the flex TCP primitives which adapt to type or the Coerce to Type primitive. Generally, these primitives are unreleased because work on them wasn't done or because they were only added to support a specific need. This could mean they just don't have documentation or that they might not work in future versions or that they will simply give you wrong data or crash LV under circumstances X.

Generally, I would suggest not using them unless it's known that they're stable or there really is no other choice. In the case of this primitive, it's obviously possible to get the original element by using Index Array on the source array, which may make the wiring messier, but is at least supported.

[dadreamer]

As it checks for array boundaries too, exact replacement for this VI should be the following:

And I don't see any reasons for using that mysterious VI, because the speed of its execution is nearly the same as the combination Index Array + Replace Array Subset has (tested this on large arrays being indexed and swapped in the loop). Whatever that "top level swap operation" means, there are no real advantages.

[Bob_Schor]

Thanks, tst and dadreamer, for clarifying that it is not only "safe", but probably "desirable", to forget about this mysterious, buried, undocumented, enigmatic function.  It does have a neat icon, but as dadreamer shows, if you need the functionality you can "build it yourself" (and, duh, document it yourself) without a significant decrease in speed.  Indeed, if the "messiness" of the demonstrated equivalence bothers you, you could wrap it up as a sub-VI and make a nice icon that looks like ... the mysterious Swap Vector function.

BS

[GregSands]

I'd guess it may be faster if the array element is a very large cluster or similar, and it swaps a pointer to the element rather than copying the data itself.  But I don't know anything about the LabVIEW internals, so that's just a guess.