LabVIEW
Code structure for data gathering—ways to avoid dynamic array size?
How important is ordering? If not, then you can copy the last row to the current and use Split/Array subset.
/Y
As a side note, the link didn't work for me for some reason, went into a totally different page. I did find the right page in the end through search
I have thought about your problem and decided to try something.
First, I defined the tasks:
1. Determine if new tracks need to be created. This is implemented in your test VI as Random >= 0.99.
2. Add new point for each existing track. (tracking algorithm)
3. Test new points for boundary limits. (In Range & Coerce?)
4. Remove tracks which hit boundaries and send to parallel loop. (Right inner For loop)
Next I considered some alternate data structures:
1. Use integers? Join into one larger integer rather than cluster? { You are processing images, I think. Thus the coordinates of a pixel representing the position of the item to be tracked may be represented by 2 integers, probably 16-bit integers. This is half of the data space required by two SGL coordinates. By combining to a single U32 (or U64 to include timing), the data can be processed as an array of integers rather than an array of cluster of two SGL. }
2. Use complex? { Credit altenbach for pointing out that complex can make things simple. The cluster of coordinates could be replaced by one CSG (Complex Single) and then processed as an array as with the integers above. If non-integer values are required this may be the preferred route. }
3. Use named queues with name representing start of track - location and time? { Use Join Numbers to combine X, Y, and t values (of the first element of a track) to a U64 then typecast to string. This string will be unique for each track. Use this as the name of a named queue. The combined number can be the element of the queue because it contains all the information required. Each time a point is added to the queue by the Tracking Algorithm, the X, Y, and t values for that point are placed into the queue. }
4. When removing a track just pass name of queue to other loop where it will be flushed and released. { To remove a track, replace the name of the track queue with a default value which will not occur in the data and pass the name to the Consumer loop. In the consumer loop the named queue is Released and all the data extracted. }
I put together a VI which implements 1, 3, and 4 (struct.4.vi). I also modified your VI slightly (struct.2.vi) to get some information about how it worked. I tested them with 20000, 200000, and 2000000 iterations. I used the Profiler to test the time and memory use. While that has some limitations I think it is a way to make reasonable comparisons.
Iterations Time kBytes (struct.2) Time kBytes (struct.4)
20000 1 8900 5.5 13.6
200000 236 20500 54.7 13.6
2000000 Abort after 1936 s 53800 550 13.6
For smaller sets the struct.2.vi is faster although the memory usage is much greater. The time of struct.2.vi appears to increase exponentially withthe number of iterations while the time of struct.4.vi increases linearly.
I have attached the VIs in LV2012. I used some features (Subdiagram Labels) not available in earlier versions. The image below shows the BD. The unshown cases are just wired straight through.
Note that the Enqueuing on the named queues is done using the Enqueue Element at Opposite End function rather than the standard Enqueue. The reason is that this makes it LIFO (Last In First Out) buffer rather than the standard FIFO behavior of a queue. This makes it easy to get the previous value required for the tracking algorithm.
Note that the boundary tests take place in the same case as the tracking algorithm so that only one element coordinate need be present at any time. This will be two coordinates in the real system if you also need to check X boundaries.
The Queue Names array is initialized with Max tracks elements of "No Queue". The constant "FFFF FFFF FFFF FFFF" in hex display mode serves as the No Queue default value. This value cannot occur in the combination of X, Y, and t. It is unlikely that the original images have 65536 pixels in each axis and the maximum value of an I32 ( the iteration count used as "t") is 2^31-1 = 7FFF FFFF. When a track is added, the first No Queue in the array is replaced by the string created by combining integer values of X, Y, and t of the first element of the track. When a track is removed, the track name is repleced by No Queue again.
Lynn
