More exotic array indexing

[Gary Rubin]

I've been working with Matlab recently and have been really impressed with some of its array indexing capabilities, in particular the ability to use an vector as the index argument and a boolean array for indexing.

For example, it would be nice to be able to do the following in Labview LabVIEW:

http://forums.lavag.org/index.php?act=attach&type=post&id=5989

Given LabVIEW's polymorphic operators (i.e. same operator for scalar, vector, matrix, etc. inputs), I would naively think this would be feasible.

I could clearly write subvis to replicate this behavior but I don't see any way to do it without some sort of looping, which would be slower than a native capability.

[Mellroth]

QUOTE(Gary Rubin @ May 31 2007, 02:45 PM)

...Given LabVIEW's polymorphic operators (i.e. same operator for scalar, vector, matrix, etc. inputs), I would naively think this would be feasible.

I could clearly write subvis to replicate this behavior but I don't see any way to do it without some sort of looping, which would be slower than a native capability.

This has been on my wish list for a very long time (added on NI wish list).

I would also like to see array functions to copy values between arrays in one call, i.e. without using loops and without the need to first get the values then set the values.

E.g. copy indices 1,3,9 from array-1 to indices 2,8,12 in array-2 directly.

/J

[Mike Ashe]

I did a fair amount of this last year on a project using LabVIEW Embedded and Matlab. I had to do it using loops and under NDA, so I can't post that code, but what you want isn't a huge amount of work.

The problem becomes that MATLAB is naturally polymorphic with array dimension size and LabVIEW is not. I think this can be generalized using variants and XNodes and/or polymorphic VIs, but to get rid of looping will require NI. I'd love to see this. The only downside is that it will probably be another $1000.00 toolkit

[Gary Rubin]

QUOTE(Mike Ashe @ May 31 2007, 09:23 AM)

I did a fair amount of this last year on a project using LabVIEW Embedded and Matlab. I had to do it using loops and under NDA, so I can't post that code, but what you want isn't a huge amount of work.

Mike,

I understand that your NDA may prevent you from saying much, but can you talk about the nature of how you tied Labview Embedded and Matlab together?

Gary

[Mike Ashe]

QUOTE(Gary Rubin @ May 31 2007, 09:27 AM)

Mike,

I understand that your NDA may prevent you from saying much, but can you talk about the nature of how you tied Labview Embedded and Matlab together?

I didn't tie, I translated.

LabVIEW Embedded did not (and does not currently as far as I know, someone correct me if I am out of date) support calling MATLAB code. We were taking algorithms in MATLAB and translating them into LabVIEW Embedded for the AD Blackfin processor. To do that I (we) made up several libraries to handle the MATLAB style matrix manipulations. But we only did it for 1,2 and 3D matrices. I think variants and XNodes could be used to generalize to N-dim.

[Gary Rubin]

QUOTE(Mike Ashe @ May 31 2007, 09:42 AM)

I didn't tie, I translated.

LabVIEW Embedded did not (and does not currently as far as I know, someone correct me if I am out of date) support calling MATLAB code. We were taking algorithms in MATLAB and translating them into LabVIEW Embedded for the AD Blackfin processor. To do that I (we) made up several libraries to handle the MATLAB style matrix manipulations.

I see. Thanks.

I was thinking you were passing data between Labview Embedded and Matlab.

[Mike Ashe]

QUOTE(Gary Rubin @ May 31 2007, 09:44 AM)

I was thinking you were passing data between Labview Embedded and Matlab.

I don't see how you could do that on an embedded processor. The problem isn't so much LabVIEW, as it is MATLAB. If you can get MATLAB on the target I think you could get them to communicate. Perhaps with a custom board running QNX. I believe LabVIEW will target that now, but I'm not sure about MATLAB.

[Aristos Queue]

QUOTE(Gary Rubin @ May 31 2007, 07:45 AM)

I could clearly write subvis to replicate this behavior but I don't see any way to do it without some sort of looping, which would be slower than a native capability.

What would make it slower than a native capability? Let's say we did make the Index Array have the behavior you request. The code under the hood would be something similar to the G code. For example, your array of int32s as indicies would be something like:

 outputArray.capacity(indexArray.size()); for (i = 0; i < indexArray.size(); ++i) {	outputArray.push_back(inputArray[indexArray[i]]); }

All the same stuff you'd do in G.

There may be other reasons to add this functionality to the Index Array primitive, but speed/performance isn't a valid reason (IMHO).

[Mike Ashe]

QUOTE(Aristos Queue @ May 31 2007, 10:26 AM)

All the same stuff you'd do in G.

There may be other reasons to add this functionality to the Index Array primitive, but speed/performance isn't a valid reason (IMHO).

It used to be that speed/performance was a very valid reason. You could implement the example you give above in G and in a CIN or DLL in C and the performance difference was pretty large. I know that NI has made a lot of optimizations in how LabVIEW handles arrays in recent versions. I was wondering if you have any up to date benchmarks on the relative difference between G and C"whatever the flavor of choice" array performance today?

[Aristos Queue]

QUOTE(Mike Ashe @ May 31 2007, 09:37 AM)

It used to be that speed/performance was a very valid reason. You could implement the example you give above in G and in a CIN or DLL in C and the performance difference was pretty large. I know that NI has made a lot of optimizations in how LabVIEW handles arrays in recent versions. I was wondering if you have any up to date benchmarks on the relative difference between G and C"whatever the flavor of choice" array performance today?

I don't. Maybe NI does somewhere.

[Eugen Graf]

You can do it so or use OpenGs index array VI.

Eugen

[Jim Kring]

QUOTE(Gary Rubin @ May 31 2007, 05:45 AM)

For example, it would be nice to be able to do the following in LabVIEW:

Strange... it seems to work on my copy of LabVIEW.

http://forums.lavag.org/index.php?act=attach&type=post&id=5994''>http://forums.lavag.org/index.php?act=attach&type=post&id=5994'>http://forums.lavag.org/index.php?act=attach&type=post&id=5994

[Neville D]

QUOTE(Gary Rubin @ May 31 2007, 05:45 AM)

ability to use an vector as the index argument and a boolean array for indexing.

http://forums.lavag.org/index.php?act=attach&type=post&id=5989

Check out OpenG's "Conditional Auto-indexing Tunnel" (quite a mouthful of a name) under the array tools. It does exactly that.

Jim Kring posted a blog article on it recently as well.

Neville.

[Ton Plomp]

QUOTE(Jim Kring @ May 31 2007, 06:47 PM)

Strange... it seems to work on my copy of LabVIEW.

http://forums.lavag.org/index.php?act=attach&type=post&id=5994''>http://forums.lavag.org/index.php?act=attach&type=post&id=5994'>http://forums.lavag.org/index.php?act=attach&type=post&id=5994

Jim,

We're not that colour/color blind.

Ton

[PJM_labview]

QUOTE(Jim Kring @ May 31 2007, 09:47 AM)

Strange... it seems to work on my copy of LabVIEW.

http://forums.lavag.org/index.php?act=attach&type=post&id=5994''>http://forums.lavag.org/index.php?act=attach&type=post&id=5994'>http://forums.lavag.org/index.php?act=attach&type=post&id=5994

Ya,

Work on mine too.

PJM

[Mike Ashe]

The OpenG index works with 2D as well, but not the Conditional (so far).

[Gary Rubin]

QUOTE(Aristos Queue @ May 31 2007, 10:26 AM)

There may be other reasons to add this functionality to the Index Array primitive, but speed/performance isn't a valid reason (IMHO).

Based on this comment, I did a little playing around in LV7.1.1 with some simple operations both inside and outside loops, i.e.

this: http://forums.lavag.org/index.php?act=attach&type=post&id=6016

vs.

this: http://forums.lavag.org/index.php?act=attach&type=post&id=6015

I was really surprised to find out that they take the same amount of time. I can't find it anywhere, but didn't there used to be an App Note that said that the first way is more efficient than the second?

Gary

[Ton Plomp]

QUOTE(Gary Rubin @ Jun 4 2007, 02:08 PM)

Based on this comment, I did a little playing around in LV7.1.1 with some simple operations both inside and outside loops, i.e.

this: http://forums.lavag.org/index.php?act=attach&type=post&id=6016

vs.

this: http://forums.lavag.org/index.php?act=attach&type=post&id=6015

That is a good example of compiler optimization, if you change the constant to a control, the code should not run with the same speed.

In LabVIEW 8 you can see this with 'constant folding'

Ton

[Gary Rubin]

QUOTE(tcplomp @ Jun 4 2007, 09:05 AM)

That is a good example of compiler optimization, if you change the constant to a control, the code should not run with the same speed.

Very good point. If I replace the constant with a the Random Number primitive, the array implementation is 25 times faster than the loop implementation.

[Omar Mussa]

QUOTE(Gary Rubin @ Jun 4 2007, 06:11 AM)

Very good point. If I replace the constant with a the Random Number primitive, the array implementation is 25 times faster than the loop implementation.

That's not necessarily a valid comparison -- the 25x faster is misleading. The reason replacing the constant with a random number generator is not a valid performance test is because in the FOR LOOP version, you actually are generating N random numbers while in the primitive version you generate 1 random number.

[Gary Rubin]

QUOTE(Omar Mussa @ Jun 4 2007, 10:37 AM)

That's not necessarily a valid comparison -- the 25x faster is misleading. The reason replacing the constant with a random number generator is not a valid performance test is because in the FOR LOOP version, you actually are generating N random numbers while in the primitive version you generate 1 random number.

You are correct.

I need to stop trying to think on Monday mornings. It just isn't working out well...

That means my previous question still applies. Am I just imagining a past App Note that recommended operating on arrays rather than on each element inside a for loop?

[Omar Mussa]

QUOTE(Gary Rubin @ Jun 4 2007, 07:44 AM)

Am I just imagining a past App Note that recommended operating on arrays rather than on each element inside a for loop?

(I believe) It is correct that operating on arrays is faster than operating on each element inside a for loop - its just that your test methodology was faulty.

[Aristos Queue]

QUOTE(Gary Rubin @ Jun 4 2007, 09:44 AM)

You are correct.

I need to stop trying to think on Monday mornings. It just isn't working out well...

That means my previous question still applies. Am I just imagining a past App Note that recommended operating on arrays rather than on each element inside a for loop?

Try putting the random number generation node *outside* the loop and then wire it through the loop tunnel. That should give comperable results to wiring the array directly.

[eaolson]

QUOTE(Gary Rubin @ Jun 4 2007, 09:44 AM)

Am I just imagining a past App Note that recommended operating on arrays rather than on each element inside a for loop?

No, because I remember the same thing. In fact, I the example it used is pretty similar to the attached one, with no contants involved. As I recall, the difference in speed was explained as being because LV was able to reuse a buffer in the array case, but had to reallocate it each loop in the For case.

[Aristos Queue]

QUOTE(eaolson @ Jun 4 2007, 01:42 PM)

No, because I remember the same thing. In fact, I the example it used is pretty similar to the attached one, with no contants involved. As I recall, the difference in speed was explained as being because LV was able to reuse a buffer in the array case, but had to reallocate it each loop in the For case.

I think you're thinking of a *while* loop.

In a For Loop, since we know at the start how many elements will be needed, the output array can be allocated right away.

With a while loop, it gets reallocated on each iteration to grow as needed.