01-24-2006 12:34 PM - edited 01-24-2006 12:34 PM
Error 1042 occurred at Call By Reference Node in Calc Mandel Rectangle.vi ->Calc Mandel Rectangle.vi ->Get Mandelbrot Image.vi ->Mandelbrot Test.vi Possible reason(s): LabVIEW: Attempted recursive call.
Message Edited by CoastalMaineBird on 01-24-2006 12:36 PM
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-25-2006 07:39 AM - edited 01-25-2006 07:39 AM
Message Edité par Jean-Pierre Drolet le 01-25-2006 08:41 AM
LabVIEW, C'est LabVIEW
01-25-2006 07:44 AM
01-25-2006 07:48 AM
01-25-2006 09:48 AM
OK, that's what I surmised by observation. Since the error message came from TWO levels deep, it seems that the first level was OK, but it choked when trying to go deeper.
2. The VI is already in memory so the time penalty is less severe to reinstanciate it than to open it from file.
This is true if you DO NOT CLOSE it. Normally I'm in the habit of closing the ref when I'm done with it. In this case, I would subdivide a rectangle into 4 quadrants, open a ref, call myself 4 times, and close the ref. If I omit the CLOSE part, the time penalty is substantially reduced (probably because the next OPEN REF re-uses the same info).
However if you recursively call the VI in a loop, you can open a VI reference outside the loop and reuse it in the the loop, closing it afterwards outside the loop.
Yes, I was doing that. But the CLOSE function apparently causes the next OPEN REF to have to do all the work over again.
Usually when the user doesn't notice, I don't worry about time optimization.
Sensible, but when a C version produces a picture in about 1/100 the time, I would call that noticable. And I am trying to produce a QuickTime movie of these images, so I'd like to generate them as fast as possible.
3. Recursion in LabVIEW is not very efficient.
I am coming to realize that. I have used it to delete a disk folder hierarchy, and to traverse a VI and its children, and its children's children, etc., but I wasn't concerned with speed in either case. Now I am.
There is always a way to code your VI in such a way that it doesn't use recursion by building a data stack (data for each level in an array stored in a shift register of your loop).
I will look into that. This project was intended to introduce my apprentice programmer to the idea of recursion, and it's an elegant use of it in theory. However in practice, it's dog slow.
Thanks for your thoughts.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-25-2006 09:53 AM
Yeah. Unfortunately, this was intended as a tool to introduce the concept of recursive procedures to my apprentice programmer.
I suppose his joy will be increased when he discovers real recursion in a C program later on...
In the meantime, I guess his next task will be "alternative ways to solve a problem". 😆
Thanks for your thoughts.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-25-2006 10:17 AM
01-25-2006 12:58 PM
LabVIEW, C'est LabVIEW
01-25-2006 02:25 PM
LabVIEW, C'est LabVIEW
01-25-2006 07:00 PM
Unfortunately (and surprisingly), the stack-based method is considerably slower than the recursive method.
Timings for the default picture:
OS X + LV 7.1.1 on 2x2.0 GHz G5: Stack : 1083 1082 1083 mSec Recursive: 687 689 690 mSec Win2k + LV 7.0 on 1x 1.5 GHz P4: Stack : 1373 1410 1392 mSec Recursive: 1064 1037 1064 mSec
Apparently, the memory-management requirements of the queue take longer than the VI-ref management of the recursive method.
Comments?
Blog for (mostly LabVIEW) programmers: Tips And Tricks