LabVIEW
Conditional Last Value?
I just realized that the self-explanatory "Conditional Indexing" feature of a Loop introduced in LV 2012 has an interesting feature:
You can actually have a conditional Last Value. Unfortunately, it is not very useful, since, if the condition is False, the returned value appears to be the default of the wire type (in the illustration above, it would be 0). I have no problem with that particular value, but I am just questioning the usefulness of the feature.
If you are not indexing the output of a loop, you can then use something like this, which gives you the opportunity to at least chose what value to output in each case:
Now I am sure that our LabVIEW aces have already found a zillion use-cases for this feature, but I haven't...
Actually, it outputs the last value that had a TRUE going to the conditional part of the tunnel. Since your example always has a FALSE, then it will be the default value.
Yeah, I haven't found a real reason to use it either. But I'm also still working in 2011 SP1.
Correct, and I should have formulated this differently: what happens in case all conditions are FALSE (as illustrated in my minimalist example)?
In the indexing case, nothing is indexed, the array is empty, fine.
What I was missing is how the "Last Conditional Value" could replace that (which is my conception of the most general "Last Conditional Value")
(with the obvious fact that the condition should be variable and the number of iteration not necessarily 1, etc)
@X. wrote:
Correct, and I should have formulated this differently: what happens in case all conditions are FALSE (as illustrated in my minimalist example)?
Like you said, it outputs the default value for the data type.
What I was missing is how the "Last Conditional Value" could replace that
It can't, because it doesn't have the two inputs that the shift register has. It's new functionality which is essentially like a shift register with no input terminal on the left side. Incidentally, you might wish to check out what happens if you run the loop and put a value in the tunnel and then run the loop again without inputting a new value. I'm guessing that you will get the existing value, but it's also possible that you would get the default.
@zerotolerance wrote:
The attached VI shows how simple it makes searching a 1D array. Specially compared to the JKI version. I haven't done any performance test though.
Kas
I've done some testing and it is neither the fastest, nor the slowest method. It could use some optimization but is quite easy to use.
@X. wrote:
Since some want to keep this thread alive (although diverging slightly out of topic), I'll just follow up on tst's suggestion above:
@tst wrote:
Incidentally, you might wish to check out what happens if you run the loop and put a value in the tunnel and then run the loop again without inputting a new value. I'm guessing that you will get the existing value, but it's also possible that you would get the default.
The answer is: you get the default value the second time. It is definitely not behaving like an uninitialized shift register. It's a new beast.
Make me wonder.... What if its a class or a dypedef with non-default default data values>..
