LabVIEW
FGV with FOR loop?
@t.d.b wrote:
All the implementations of FGV's that I have seen, are with a While loop with a T wired to its conditional terminal.
I was wondering if using a FOR loop with N=1 makes any difference.
It makes no difference in functionality.
You can also use a feedback node. The wiring gets a bit more messy though, but you have more control over the initialization (both value as condition). A good option to know.
You can also use local variables, but this will keep the FP in executables. And each local will make a copy. So, a lesser solution.
@t.d.b wrote:As far as I have read, there should be no difference. But are there any finer points like memory optimization/timing constraints etc, that may need to be considered? Is there any particular reason why While loops are used exclusively for FGVs?
AFAIC, it's just tradition to use a while loop.
Traditions are part of any language though. If you use a while loop, people will understand at a glance. With a for loop, it will take a second look.
A while loop suggest iterating until a condition is true or false. A for loop suggest iterating over something. Although the iterations can be set to 1, intuitively, a while loop is closer to the job at hand: loop until a condition is true or false. But it's in the gray area...
Search LabVIEW like a graph! 
wiebe@CARYA wrote:You can also use a feedback node. The wiring gets a bit more messy though, but you have more control over the initialization (both value as condition). A good option to know.
99% of my Action Engines use the Feedback Node. It just seems cleaner to me to not have the loop. But once I try to hold more than 1 thing, the Feedback Node method gets messy and I will switch to the While Loop.
@crossrulz wrote:
wiebe@CARYA wrote:You can also use a feedback node. The wiring gets a bit more messy though, but you have more control over the initialization (both value as condition). A good option to know.
99% of my Action Engines use the Feedback Node. It just seems cleaner to me to not have the loop. But once I try to hold more than 1 thing, the Feedback Node method gets messy and I will switch to the While Loop.
I found feedback nodes to be slower in some cases. But the control over initialization is a bug bonus.
Another bonus is the (optional) enable input. With a shift register, you can do that with a Select, but with the FBN it's build in.
wiebe@CARYA wrote:I found feedback nodes to be slower in some cases.
I'm curious about your cases. I remember AristosQueue posting a thread where he did the speed comparisons between a Feedback Node and While Loop with Shift Register with NI's massive benchmarking system (unable to find the thread at the moment). I recall the results were that the Feedback Nodes were very slightly faster than the loop, hardly enough to worry about. But that was sever years ago.
@crossrulz wrote:
wiebe@CARYA wrote:I found feedback nodes to be slower in some cases.
I'm curious about your cases. I remember AristosQueue posting a thread where he did the speed comparisons between a Feedback Node and While Loop with Shift Register with NI's massive benchmarking system (unable to find the thread at the moment). I recall the results were that the Feedback Nodes were very slightly faster than the loop, hardly enough to worry about. But that was sever years ago.
I used the FBN enable, so that might be a factor. In the while loop, this was handled in a case propagating the old value or selecting a new value. The FBN used the enable, and I suspect the condition forced a copy 'into' the FBN, while the loop was either a no-op or setting a value to the pointer.
It was complex though, with ~6 values, all independently enabled. The values where complex too, class objects and queue references.
