Jump to content

More exotic array indexing


Recommended Posts

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.

Link to comment

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.

:yes:

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

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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?

Link to comment

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.

Link to comment

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

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.

Link to comment

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

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

Link to comment

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

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

:oops:

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?

Link to comment

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.

Link to comment

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

You are correct.

:oops:

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.

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.