LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Steve_TDiode

Loop Tunnel Mode of Summation or Average

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

Having a For or While Loop's Tunnel Mode be capable of performing Summation would eliminate requirement of a shift register and Add primative.  This would be useful for then averaging results of data produced within the loop for example.

Perhaps even have an option (or another Mode) to automatically output the average of those summed values?

Steve

16 Comments
crossrulz
Knight of NI

Continuing the way off track...

Wiebe, if you really need that summation in a class, then it should be part of the private data.

 

Back to the tunnel...

There is such a thing as consolidating too much code.  As was stated, where does this end?  Just use a shift register to keep your sum.  This is a easily recognizable pattern.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue (NI)
NI Employee (retired)

I agree that someone should not use function state when they need object state. I don't think that translates into being cautious about creating a function that is a member of a class that uses function state. If you correctly need function state, there's no reason to be cautious about using function state in a class VI.

AristosQueue (NI)
NI Employee (retired)

Back on the core topic... this statement is interesting:

 

Crossrulz wrote:

> There is such a thing as consolidating too much code.

 

I agree, but we might not actually be there. If a tunnel could be assigned a reduction function (i.e. a function that blends together results from successive iterations of a loop to produce a single output) and then displayed that function's icon as the tunnel glyph, it would simplify the programming considerably.

 

Assigning "helper VIs" to small bits of LabVIEW code is a topic that comes up semi-regularly, and, to me, tunnel behavior and In Place Element pairing are the two most interesting aspects of that.

wiebe@CARYA
Knight of NI

Continuing the way off track...

Wiebe, if you really need that summation in a class, then it should be part of the private data.

Well, yes, exactly the point. PtByPt style VI's are not (always) useful, exactly because they don't allow that.

 

Summation isn't the problem. A PtByPt FFT or PID is a real challenge (since they use PtByPt subVI's). Rewriting them means completely turning them inside out. This is a pity since all the hard work that has been done by the PtByPt team is not useful when I (anyone really) use OO.

 

Feels to me like having 200 VHS video's and no VHS player...

wiebe@CARYA
Knight of NI

In C++ this kind of behaviour can be done with iterators (and such).

 

It would be great if we could (back in LV) overload a method from an iterator class, and somehow tell the for loop to use that class\method as "iterator".

 

Not sure how that could be done in practice. How would the user specify this? The method must have adaptability (vim) like features. Etc.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.