Compound Boolean and Numeric Tunnels

[JW-JnJ]

So I have a problem between the most efficient way to code iterative operations and the way I usually do it for readability/simplicity

Efficient

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.

Proposed

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.

[Darin.K]

IMO, replace those shift registers in your 'Efficient' image with Feedback Nodes and you have efficient and simple and clean.

[JW-JnJ]

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.

[igagne]

Do you have any benchmarks showing the relative performance benefits? Maybe the feature request should be to optimize the compiler to recognize the clean pattern and refactor.

[JW-JnJ]

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

[GregSands]

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.

[Dragis]

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.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Compound-Boolean-and-Numeric-Tunnels/idc-p/3161127#M31...