professor_rumsdiegeige Posted March 21, 2008 Report Share Posted March 21, 2008 Hi! Is there a built-in function in Labview to extract every n-th element out of a one-dimensional array? If not, how would you create a fast (!) replacement? Thanx in advance. Link to comment
mross Posted March 21, 2008 Report Share Posted March 21, 2008 QUOTE (professor_rumsdiegeige @ Mar 20 2008, 08:24 AM) Hi!Is there a built-in function in Labview to extract every n-th element out of a one-dimensional array? If not, how would you create a fast (!) replacement? Thanx in advance. There is a pallette of array manipulation functions. You need Index Array. This is probably the most basic data manipulation function in LabVIEW and it has been present from the start. You need Index Array. Link to comment
Louis Manfredi Posted March 21, 2008 Report Share Posted March 21, 2008 QUOTE (professor_rumsdiegeige @ Mar 20 2008, 09:24 AM) Hi!Is there a built-in function in Labview to extract every n-th element out of a one-dimensional array? If not, how would you create a fast (!) replacement? Thanx in advance. Index array would work, with some programming, but much more straightforward is Decimate 1D array for what you want to do, same menu... Best Regards, Louis Link to comment
professor_rumsdiegeige Posted March 21, 2008 Author Report Share Posted March 21, 2008 Thanks, decimate array was exactly what I was looking for… regards QUOTE (Louis Manfredi @ Mar 20 2008, 02:46 PM) Index array would work, with some programming, but much more straightforward is Decimate 1D array for what you want to do, same menu...Best Regards, Louis Link to comment
Justin Goeres Posted March 21, 2008 Report Share Posted March 21, 2008 QUOTE (professor_rumsdiegeige @ Mar 20 2008, 05:50 AM) Thanks, decimate array was exactly what I was looking for… Here's a bit of code that allows you to decimate dynamically: It requires the OpenG Array library. Example File: Download File:post-2992-1206024896.vi Link to comment
Jim Kring Posted March 21, 2008 Report Share Posted March 21, 2008 QUOTE (Justin Goeres @ Mar 20 2008, 07:55 AM) Here's a bit of code that allows you to decimate dynamically: It requires the OpenG Array library. Example File: Download File:post-2992-1206024896.vi Justin, That looks like it might make for a good OpenG candidate -Jim Link to comment
Justin Goeres Posted March 21, 2008 Report Share Posted March 21, 2008 QUOTE (Jim Kring @ Mar 20 2008, 08:42 AM) That looks like it might make for a good http://forums.openg.org/index.php?showtopic=819' rel='nofollow' target="_blank">OpenG candidate The same thing occurred to me over lunch just now.... Link to comment
Yuri33 Posted March 21, 2008 Report Share Posted March 21, 2008 I find this to be the most efficient (and fastest) version: Link to comment
Norm Kirchner Posted March 22, 2008 Report Share Posted March 22, 2008 QUOTE (Yuri33 @ Mar 20 2008, 12:59 PM) I find this to be the most efficient (and fastest) version: http://lavag.org/old_files/monthly_03_2008/post-7607-1206035930.png' target="_blank"> Very Nice! I would bet that is the fastest way. Much more dynamic than the decimate too (usually what I did) Link to comment
Justin Goeres Posted March 22, 2008 Report Share Posted March 22, 2008 QUOTE (Yuri33 @ Mar 20 2008, 09:59 AM) I find this to be the most efficient (and fastest) version: I don't think that works. Or am I missing something? I reproduced the code in your screenshot (or at least I think I did), and when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 3 The result I get is Decimated Array = {0,3,6} (It should be {0,3,6,9}). Likewise, when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 4 The result I get is Decimated Array = {0,4} (It should be {0,4,8}). It's easy to find plenty of other examples where the last element in Decimated Array is missing. EDIT: A little bit more testing leads me to believe that the Yuri33's code works as long as Decimating Factor divides evenly into the size of Array. If it doesn't (i.e. if R>0 coming out of the Quotient & Remainder), the last element of Decimated Array is chopped off. Link to comment
Jim Kring Posted March 22, 2008 Report Share Posted March 22, 2008 Here's a fix for the remainder > 0 bug: Download File:post-17-1206073613.vi Link to comment
Norm Kirchner Posted March 22, 2008 Report Share Posted March 22, 2008 well when we talk about good candidates for the OpenG repository; I think we just finished the coding cycle!!! all it needs now is a cool green icon Link to comment
Aristos Queue Posted March 23, 2008 Report Share Posted March 23, 2008 Decimate Array is going to blow any custom decimation using a For Loop out of the water performance-wise. Decimate Array is able to operate without creating any copies of data. The new "array" under the hood is a subarray (as you can see by looking in the context help next time you're hovering over an output wire of that function) that stores a starting index and a stride into the original array. The later implementations that have been posted that use the array prims should be on par with Decimate Array. PS: Since you're looking at optimizations for this diagram, you might be interested in this tidbit. I've been meaning to post it for a while: http://forums.lavag.org/Another-reason-why...ons-t10406.html Link to comment
Yuri33 Posted March 23, 2008 Report Share Posted March 23, 2008 QUOTE (Justin Goeres @ Mar 20 2008, 10:04 PM) EDIT: A little bit more testing leads me to believe that the Yuri33's code works as long as Decimating Factor divides evenly into the size of Array. If it doesn't (i.e. if R>0 coming out of the Quotient & Remainder), the last element of Decimated Array is chopped off. Yes, I forgot to stipulate that my code only works when the array can be evenly divided by the decimation factor. I use that function in a program that ensures this condition elsewhere. The later modification that fixes this problem is good solution that doesn't sacrifice speed. Link to comment
Jim Kring Posted March 23, 2008 Report Share Posted March 23, 2008 QUOTE (Justin Goeres @ Mar 20 2008, 09:04 PM) I don't think that works. Or am I missing something?I reproduced the code in your screenshot (or at least I think I did), and when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 3 The result I get is Decimated Array = {0,3,6} (It should be {0,3,6,9}). Likewise, when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 4 The result I get is Decimated Array = {0,4} (It should be {0,4,8}). It's easy to find plenty of other examples where the last element in Decimated Array is missing. EDIT: A little bit more testing leads me to believe that the Yuri33's code works as long as Decimating Factor divides evenly into the size of Array. If it doesn't (i.e. if R>0 coming out of the Quotient & Remainder), the last element of Decimated Array is chopped off. Justin, I did some testing of LabVIEW's built-in decimation function. It truncates the trailing (remainder) elements. I have no idea which is the preferred behavior. One one hand, it's nice not to lose data (so you wouldn't want the data truncated), and on the other hand if you are going to create several subarrays with the decimated data, it's nice to have them all the same length (so you would want the data truncated). So, I would probably add an optional argument to this VI called truncate remainder. -Jim Link to comment
Neville D Posted March 25, 2008 Report Share Posted March 25, 2008 There is already a built-in "Decimate (continuous).vi" polymorphic VI (handles DBL's and CDB's) under Functions>Signal Processing>Signal Operations Pallet. It gives you the option to adjust the Decimation factor & start index on the fly. (Has been around for years). Neville. Link to comment
Norm Kirchner Posted March 25, 2008 Report Share Posted March 25, 2008 Well I'm sure that the same argument that I asked w/ regards to the "Mean Value" discussion applies to making this an OpenG tool; i.e. not being in the base package and also needing to have the dll associated with it Link to comment
Yuri33 Posted March 26, 2008 Report Share Posted March 26, 2008 I haven't done the test in a while, but I believe that the native implementation was much faster than the dll one supplied by NI (hence the reason I built the subVI). Also, while I've never needed to, the start index can easily be incorporated by selecting a different column (instead of hard-coded 0) to index from. Link to comment
Justin Goeres Posted March 26, 2008 Report Share Posted March 26, 2008 QUOTE (Yuri33 @ Mar 25 2008, 08:09 AM) the start index can easily be incorporated by selecting a different column (instead of hard-coded 0) to index from. But don't you get a trailing zero then in instances where the decimation doesn't come out even? That was what led me to the For-Loop implementation I posted. There may be a better way to get there (i.e. without a For Loop), but that was the motivation for adding the For Loop. I had actually implemented something very close to your method originally. Sorry, posting this on my way out the door or I'd check myself . Link to comment
Tomi Maila Posted March 26, 2008 Report Share Posted March 26, 2008 My five cents to the discussion. Link to comment
shoneill Posted March 27, 2008 Report Share Posted March 27, 2008 QUOTE (Aristos Queue @ Mar 21 2008, 11:47 PM) Decimate Array is going to blow any custom decimation using a For Loop out of the water performance-wise. Decimate Array is able to operate without creating any copies of data. The new "array" under the hood is a subarray (as you can see by looking in the context help next time you're hovering over an output wire of that function) that stores a starting index and a stride into the original array.The later implementations that have been posted that use the array prims should be on par with Decimate Array. PS: Since you're looking at optimizations for this diagram, you might be interested in this tidbit. I've been meaning to post it for a while: http://forums.lavag.org/Another-reason-why...ons-t10406.html Apologies for a bit of a thread hijack... The new info about sub-arrays (for me - Since when does LV work with sub-arrays?) is fascinating. So does this mean that we can "undecimate" a sub-array coming from the "Decimate Array" function? Does it also mean that if we do a 3x Decimate, then we have 3 sub-arrays basically all pointing to the same array in memory with different start and stride settings? I assume there are optimisations made based on the assumption that all of these sub-arrays are mutually exclusive.... What happens when we Interleave sub-arrays of the same array in the same order they were decimated? Does this simply return the original array, or does it create a copy? I suggest a new INI setting SuperFunkySubArrayWires = TRUE. I don't like LV doing things like this behind my back (Unless I program it that way). Shane. Ps I just spotted NevilleD's post..... Can this "Decimate (Continuous)" function re-create the original array? Can't this lead to a race condition if other sub-arrays are also running around? Link to comment
Neville D Posted March 27, 2008 Report Share Posted March 27, 2008 QUOTE (shoneill @ Mar 26 2008, 01:18 AM) Ps I just spotted NevilleD's post..... Can this "Decimate (Continuous)" function re-create the original array? Can't this lead to a race condition if other sub-arrays are also running around? Its not a function, its a VI with a dll call inside pointing to lvanlysis dll (which is part of the advanced package). So I guess your questions about sub-arrays are not relevant to it. Neville. Link to comment
Jim Kring Posted April 4, 2008 Report Share Posted April 4, 2008 QUOTE (Jim Kring @ Mar 20 2008, 09:42 AM) That looks like it might make for a good OpenG candidate Today, Greg Sands proposed something very similar, in the OpenG forums here: http://forums.openg.org/index.php?showtopic=835 Link to comment
GregSands Posted April 30, 2008 Report Share Posted April 30, 2008 I've done some quick benchmarking on 4 methods for decimating a 1-D array - here's the timing results: and the block diagram: Essentially the 4 techniques are 0) index and build array 1) reshape and reslice array 2) index and rebuild into current array, then truncate 3) explicitly decimate using built-in function The benchmarking code built a 40M element array, and ran each method with decimations from 1 to 10 multiple times taking the median time as the result. Plus debugging was turned off! Here's the code (LV 8.2): Download File:post-3889-1209438013.vi Apart from the built-in function, the index methods are fastest, with a slight advantage to re-using the same array. Sorry Jim, I haven't had a chance to add this to the OpenG wiki, and I'm pretty busy so may not get to it any time soon. Cheers ~ Greg Link to comment
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now