Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Compound-Boolean-and-Numeric-Tunnels/idc-p/3161127#M31...
So I have a problem between the most efficient way to code iterative operations and the way I usually do it for readability/simplicity
Simple and clean
I imagine the last way is way less efficient due to creating a matrix then working through it again.
I'm proposing a merging of these two ideas. A compound tunnel that performs the most efficient method, but doens't mess up my diagrams with a lot of crossing wires and other hard to read messes.
Note, this will only work for commutative functions (add, subtract, and, or, xor... basically anything on the Compound Arithmetic function)
I haven't decided how the selection function should work, so I leave that to the LabVIEW UI coding experts since they've done a good job so far.
IMO, replace those shift registers in your 'Efficient' image with Feedback Nodes and you have efficient and simple and clean.
Excellent point. I actually forgot about that when writing this.
However, I just realized something. Doesn't shift registers and feedback nodes stop parallelism in For loops? This method will allow the best of both worlds. Since it's commutative, it doesn't matter what order they come in and you still avoid creating an array.
Huh. Either my test method is flawed, or I might be completely mistaken in my assumptions above.
This is adding rand doubles using the two methods.
Welp, this might be knocking my idea out of the sky
I'm not sure this is a good idea for AND or OR. Usually, it would make sense to terminate the loop once you get a FALSE (for AND) or TRUE (for OR), and you can easily do that using a Conditional Terminal. I can see more use for an iterative Add or Multiply, but the code required for this using a SR or Feedback Node is minimal and far more flexible. Plus I doubt it would prevent users from generating million-element arrays when they're not needed.
As @igagne mentioned, I would strongly recommend programming for readability foremost and only worrying about optimizations when you actually see an issue. In this particular case, there is a very good chance the compiler is already going to recognize those patterns and optimze the code for you.
Also, the Parallel For Loop does support those numeric and boolean reduction operations. Therefore the post-loop reduction (e.g. build array with summation) or inline reduction (e.g. shift registers with and) would all be parallelizable.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.