"Conditional Append" at array indexing tunnel

[Greil]

Compare the upper loop(old) with the lower loop(new).
Take a close look at the loop exit.

 

Solution: Right click the indexing tunnel and select "Enable Conditional Append"

This works not only with FOR-Loops. 

History: This idea was already presented by me in May 2008 http://lavag.org/topic/7574-conditional-append/page__p__44719&#entry44719 

[RavensFan]

Then perhaps you will want to kudo the idea where it has already been presented here.  http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-auto-indexing/idi-p/918682#A123

[Greil]

yes i did it - even he copied my idea and example (proven by the link in my first post)

[JackDunaway]

This idea is too good to not Kudos twice, so Kudos.

[tst]

> ...proven by the link in my first post

The fact that something is similar to something else does not prove that it was copied.

[elset191]

"The fact that something is similar to something else does not prove that it was copied."

Not to mention that in that same thread he posted, Jim Kring posted the OpenG VI, and states that it was already available at the time.  So, Martin's wasn't wholly original either.

[falkpl]

"It's amazing what you can accomplish when you don't care who gets the credit." - Pres. Harry S. Truman

I posted this because it is something that would make my development faster.  I am sure that I was not the originator of this idea.  I bet this has been thought of by anyone who has ever built a conditional array inside of a loop. 

Actually I remember a presentation at NIWeek several years back where Dr K. (I think it was him if my memory is correct) envisioned an environment where labview was behind the sceen of lower level implementations so this indexing terminal was in itself just another vi that could be edited with LabVIEW to implement just such a feature.  Now thast would be supercool.  If I have to start footnoting my posts I will probably go crazy. 

Anyway kudos to all who can use such a feature.

[JÞB]

Frankly I like the Idea!  No matter who's (whom's?) it is.  but I'd prefer an implementation that is more related to the true functions "Concatanate" and "Build Array" like thus

[tst]

Jeff, the problem with your suggestion is that it still requires considerable space and work. You're not gaining much over the current situation. Your image is equivalent to simply wrapping a case structure around the BA prim.

When adding a single element, concatenate and build are the same thing. I did actually post a suggestion here which offers a real concat and I also suggested there combining it with this idea. This sample image also shows the savings in space and work.

[Rob_Calhoun]

We use a conditional build array very frequently in our code and I strongly support adding this to LabView. (Incidentally I am kudos'ing all variations of this idea by all posters, as I don't care who "invented it"; it is based a very common code pattern and it is unsurprising that there are multiple "inventors".)

The implementation should be compatible with the existing "Conditional" terminal of For Loops. (Probably that would have to be renamed "Conditional Termination" when the new "Conditional Build" is added.) One option would look like this:

 

I am trying match the feel of the existing Conditional Termination terminal, which is free-floating. (This also lets you make the wires shorter.) Ideally one would be able to build the output on either a "true" or "false" Boolean, similar to the dual functionality of the Conditional termination terminal. An unresolved problem is how to badge the "N": there is very little room left and my suggested badging above is incomprehensible.

I wanted to present how we handle this in LV 2009 and earlier. We don't use the OpenG function "Conditional Auto-Indexing Tunnel" because it only works for built-in data types and many of our arrays contain large clusters. Instead we have a generic function that returns the "true" indices of a Boolean array. (That is, it maps {T, F, T, T} => {0,2,3}.) This requires a second For Loop but it then can be used with any type of data that Index Array can index:

In most cases this is faster than having a case statement inside a loop because LabView can identify the size of both output arrays from inspection and pre-allocate. (LabView cannot preallocate in the "conditional indexer" function, so we wrote a difficult-to-read but highly optimized version.) A a code pattern this works very well, especially if you make the code pattern on the right into its own VI and add that VI to your palette as "Place VI Contents".

Nevertheless, the whole thing is kind of a hack and it would be much better to have a conditional-build-array built into LabView. So, Kudos to Martin and everyone else who suggested this.

-Rob

[JackDunaway]

As usual, I have enjoyed reading Rob's detailed post. I think I read a post a while ago where altenbach proposed a similar method that JK eventually wanted to include in the OpenG package?

One change: the "Include" terminal must be physically attached to each auto-indexed output, not free-floating. For instance, you could have multiple auto-indexed outputs with independent inclusion criteria. tst's illustration above is nice, minus the incomprehensible "?" below the auto-indexed output. Maybe just another small [] that's colored the BOOL Green.