Gary Rubin Posted June 1, 2007 Report Share Posted June 1, 2007 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. Quote Link to comment
Mellroth Posted June 1, 2007 Report Share Posted June 1, 2007 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 Quote Link to comment
Mike Ashe Posted June 1, 2007 Report Share Posted June 1, 2007 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 Quote Link to comment
Gary Rubin Posted June 1, 2007 Author Report Share Posted June 1, 2007 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 Quote Link to comment
Mike Ashe Posted June 1, 2007 Report Share Posted June 1, 2007 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. Quote Link to comment
Gary Rubin Posted June 1, 2007 Author Report Share Posted June 1, 2007 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. Quote Link to comment
Mike Ashe Posted June 1, 2007 Report Share Posted June 1, 2007 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. Quote Link to comment
Aristos Queue Posted June 1, 2007 Report Share Posted June 1, 2007 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). Quote Link to comment
Mike Ashe Posted June 1, 2007 Report Share Posted June 1, 2007 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? Quote Link to comment
Aristos Queue Posted June 1, 2007 Report Share Posted June 1, 2007 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. Quote Link to comment
Eugen Graf Posted June 1, 2007 Report Share Posted June 1, 2007 You can do it so or use OpenGs index array VI. Eugen Quote Link to comment
Jim Kring Posted June 1, 2007 Report Share Posted June 1, 2007 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 Quote Link to comment
Neville D Posted June 1, 2007 Report Share Posted June 1, 2007 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. Quote Link to comment
Ton Plomp Posted June 1, 2007 Report Share Posted June 1, 2007 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 Quote Link to comment
PJM_labview Posted June 1, 2007 Report Share Posted June 1, 2007 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 Quote Link to comment
Mike Ashe Posted June 2, 2007 Report Share Posted June 2, 2007 The OpenG index works with 2D as well, but not the Conditional (so far). Quote Link to comment
Gary Rubin Posted June 5, 2007 Author Report Share Posted June 5, 2007 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 Quote Link to comment
Ton Plomp Posted June 5, 2007 Report Share Posted June 5, 2007 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 Quote Link to comment
Gary Rubin Posted June 5, 2007 Author Report Share Posted June 5, 2007 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. Quote Link to comment
Omar Mussa Posted June 5, 2007 Report Share Posted June 5, 2007 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. Quote Link to comment
Gary Rubin Posted June 5, 2007 Author Report Share Posted June 5, 2007 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? Quote Link to comment
Omar Mussa Posted June 5, 2007 Report Share Posted June 5, 2007 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. Quote Link to comment
Aristos Queue Posted June 5, 2007 Report Share Posted June 5, 2007 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. Quote Link to comment
eaolson Posted June 5, 2007 Report Share Posted June 5, 2007 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. Quote Link to comment
Aristos Queue Posted June 6, 2007 Report Share Posted June 6, 2007 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.