Conditional Append

[MartinGreil]

Compare the upper loop with the lower loop.

Take a close look at the loop exit.

greetings from

martin

[TobyD]

QUOTE (MartinGreil @ May 2 2008, 08:30 AM)

Take a close look at the loop exit.

That's a great idea :thumbup:

[LAVA 1.0 Content]

QUOTE (MartinGreil @ May 2 2008, 11:30 AM)

Compare the upper loop with the lower loop.

Take a close look at the loop exit.

greetings from

martin

Help me understand this post, please.

How does that image differ from using the "Conditional Terminal" that is now availabe in the For Loop under LV 8.5 plus.

Never mind!

You are looking to control in the data gets added to the arry being built in the tunnel. "Duh"

Ben

[crelf]

QUOTE (MartinGreil @ May 2 2008, 11:30 AM)

Compare the upper loop with the lower loop.

I like it I think it's initially going to be a little unintuative (with a tunnel build having the possibility of fewer elements than the iteration count) but I think it's a good idea. :thumbup:

[ooth]

I love that idea. I'm so sick of constantly making that case structure with the build array in it. It always takes up too much space in my diagrams.

[MartinGreil]

QUOTE (neB @ May 2 2008, 05:56 PM)

... that is now availabe in the For Loop under LV 8.5 plus.

sorry, I have only LV8.2.1 installed.

(I had this idea in december 2006, and found that vi today on my old computer. As far as i know it was sent to NI but never got a reply.)

[LAVA 1.0 Content]

Just a quick idea for the discussion...

Download File:post-6703-1209759412.vi

[MartinGreil]

Sure, a SubVI is a solution - but keep in mind there are hundreds of types possible. The DBL was just used to make an example.

So finally your code has to deal with variant data type and set the SubVI to re-entrant enabled.

Option "re-entrant enabled" will lead to waste lot of memory when using lot of instances and big arrays.

And of course passing data to the SubVI is less efficient than having the data in the local vi.

You could improve your VI by passing the Loop's "N" to your SubVI. Then (only in the last iteration) give the array to the output. I don't know if LV can release the allocated memory during the loop of the last call.

The LabVIEW generated code would be much more efficient than using a SubVI.

[T_Schott]

like this idea

control the data that will be indexed...

[Rolf Kalbermatter]

QUOTE (MartinGreil @ May 2 2008, 10:30 AM)

Compare the upper loop with the lower loop.

Take a close look at the loop exit.

greetings from

martin

It would mean that every autoindexing output tunnel in a loop has an (optional) boolean.

Interesting idea but Ohhhh so unintuitive! One more of those features even LabVIEW cracks would only discover by accident after years of programming.

Rolf Kalbermatter

[Jim Kring]

QUOTE (MartinGreil @ May 2 2008, 08:30 AM)

Compare the upper loop with the lower loop.

Take a close look at the loop exit.

greetings from

martin

That's a great idea. In fact, OpenG already has such a function called Conditional Auto-Indexing Tunnel.

This function started as an item on my LabVIEW wish-list, many years ago

-Jim

PS -- Come on crelf and rolfk! Don't tell me that you guys don't know about this OpenG function

[crelf]

QUOTE (Jim Kring @ May 4 2008, 01:02 PM)

PS -- Come on crelf and rolfk! Don't tell me that you guys don't know about this OpenG function

Ummm, errr, sure I do...

[Rolf Kalbermatter]

QUOTE (Jim Kring @ May 4 2008, 01:02 PM)

PS -- Come on crelf and rolfk! Don't tell me that you guys don't know about this OpenG function

Actually I do but never used it so far. Reason for me is that it is in fact still unoptimized since you first create the entire array and then build it into the really desired array although this last step is happening rather optimal. In a lot of cases I end up doing more complex algorithmes anyhow that avoid the data memory fragmentation caused by the Build Array inside the case structure altogether.

Happened to help me reduce the runtime of a particular function at some point from about 50 seconds to far less than 1 second at one time. Of course writing that function took me also a bit more than the inverse proportional time of what the first approach with simple Build Array in a case structure had taken me. But considering that my customer has probably saved in this way I don't know how many hours of waiting for the calculation result since, I feel this was well invested development time and it was fun and educational too to do it.

The OpenG function would likely have been only slightly slower but would have taken up temporarely more than double the memory of my approach and that was at that time not unconsiderable in relation to the available physical memory.

Whenever I hear someone swear at how bad the speed of programs written in LabVIEW is I just smile and think about this. It's not that LabVIEW is slower than C in most cases or that it is that much harder to write well performing algorithmes in LabVIEW but the simple fact that it is a lot easier to write an algorithme in LabVIEW at all. Sometimes those algorithmes end up in a way that a C programmer would not even think about to do because he needs to deal with every memory allocation anyhow so is likely to look for an algorithme where he does not need do this all over in his code over and over again.

But the build in feature as suggested by the OP would be even more optimal than the OpenG function although of course not as optimal as the unconditional For loop auto indexing.

If I would be a LabVIEW engineer I would make that conditional auto indexing generate the same machine code as what is used for while loops. There the intermediate array is started of with some intial size and then whenever it gets to small the currently allocated size is doubled. At the end of the loop the array memory is resized to its really used size once more. This is the most optimal approach in terms of memory (re)allocations and data copying for generic situations where you do not know the finally needed size beforehand.

And one last note: I wonder when there will be a patent filed by NI for exactly this . From my understanding of patents it would not be valid since this idea has been published here prior to such a patent filing but who would be going to court with this?

Rolf Kalbermatter

[Aristos Queue]

QUOTE (MartinGreil @ May 2 2008, 04:43 PM)

Option "re-entrant enabled" will lead to waste lot of memory when using lot of instances and big arrays.

And of course passing data to the SubVI is less efficient than having the data in the local vi.

<snip> QUOTE

The LabVIEW generated code would be much more efficient than using a SubVI.

The above assertions can all be said to be "sort of" true insofar as it depends greatly upon how the subVI is written. They are not true of all subVIs, even all reentrant subVIs, under all conditions. Specifically, I'm not convinced they would have to apply to the specific subVI under discussion if it were written correctly.

http://lavag.org/old_files/monthly_05_2008/post-6703-1209759395.jpg' target="_blank">

[Michael Aivaliotis]

I like this idea. Along the same lines (or maybe this is hijacking), why does a 1D array always become a 2D on for loop borders? Why can't we concatenate a 1D array at the border. It seems that tunnel has the potential to do a lot more than it can right now in regards to array manipulation.

[Bjarne Joergensen]

QUOTE (Michael_Aivaliotis @ May 5 2008, 09:02 AM)

I like this idea. Along the same lines (or maybe this is hijacking), why does a 1D array always become a 2D on for loop borders? Why can't we concatenate a 1D array at the border. It seems that tunnel has the potential to do a lot more than it can right now in regards to array manipulation.

I can't se the picture of what you are talking about. What is wrong ?

regards

Bjarne

[TobyD]

QUOTE (rolfk @ May 4 2008, 05:34 AM)

Interesting idea but Ohhhh so unintuitive!

I don't think it is any more unintuitive than shift registers, conditional stop terminals on for loops, the "concatenate inputs" option on a build array node, feedback nodes, or auto indexing in general. I could go on. These are all features of LabVIEW that make life much easier/faster to use, but to a new wire worker looking at a block diagram they might not immediately make sense.

That said, once you understand how these features work, it quickly becomes second nature to implement them in your code.

[crelf]

QUOTE (TobyD @ May 5 2008, 11:51 AM)

That said, once you understand how these features work, it quickly becomes second nature to implement them in your code.

Yep - you're absolutely right.

[Yair]

I think this would be a great feature and one which I also wanted for a long time. I use the OpenG VI all the time, but this would be much better.