Jump to content

Extract every n-th element out of an 1-dimensional-array


Recommended Posts

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 post
Share on other sites

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 post
Share on other sites

QUOTE (Yuri33 @ Mar 20 2008, 12:59 PM)

Very Nice!

I would bet that is the fastest way. Much more dynamic than the decimate too (usually what I did)

Link to post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

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 :P.

Link to post
Share on other sites

QUOTE (Aristos Queue @ Mar 21 2008, 11:47 PM)

Apologies for a bit of a thread hijack... :unsure:

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 post
Share on other sites

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 post
Share on other sites
  • 4 weeks later...

I've done some quick benchmarking on 4 methods for decimating a 1-D array - here's the timing results:

post-3889-1209437233.png?width=400

and the block diagram:

post-3889-1209437738.png?width=400

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 post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.