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

[professor_rumsdiegeige]

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.

[mross]

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.

[Louis Manfredi]

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

[professor_rumsdiegeige]

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

[Justin Goeres]

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

[Jim Kring]

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

[Justin Goeres]

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

[Yuri33]

I find this to be the most efficient (and fastest) version:

[Norm Kirchner]

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)

[Justin Goeres]

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.

[Jim Kring]

Here's a fix for the remainder > 0 bug:

Download File:post-17-1206073613.vi

[Norm Kirchner]

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

[Aristos Queue]

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

[Yuri33]

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.

[Jim Kring]

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

[Neville D]

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.

[Norm Kirchner]

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

[Yuri33]

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.

[Justin Goeres]

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 .

[Tomi Maila]

My five cents to the discussion.

[shoneill]

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?

[Neville D]

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.

[Jim Kring]

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

[GregSands]

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