Loop Tunnel Mode of Summation or Average

[Steve_TDiode]

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

[Intaris]

Where to stop, Sum, Min, Max, Averaging, Variance, Standard deviation, Skew.......

I think, for readability, it's best not to try to attach too much diverse functionality to this aspect of LabVIEW.  A simple sub-VI to perform all of the functionality you require will achieve the same end result and will, IMHO, be more readable.

[wiebe@CARYA]

Where to stop, Sum, Min, Max, Averaging, Variance, Standard deviation, Skew.......

Almost exactly what I was thinking.

A simple sub-VI to perform all of the functionality you require will achieve the same end result and will, IMHO, be more readable.

---

That could be a bit trickier though. That VI (basically PtByPt style) should be re-entrant so each instance has it's own data. However, that doesn't work well with classes. A method using the VI (incl. any PtByPt VI) will fail when it's using in a for loop of objects, since each object of the same class will use the same instance.

I don't mean to say the idea is good. Just that PtByPt style VI's are not a good idea (at least not when programming OO).

[AristosQueue (NI)]

---

wiebe wrote:
since each object of the same class will use the same instance.

---

In what universe? Not the one I designed and put into LabVIEW. LabVIEW class objects don't share instances the way you're describing.

[wiebe@CARYA]

In what universe? Not the one I designed and put into LabVIEW. LabVIEW class objects don't share instances the way you're describing. 

In our universe. And I just tested it and this is how it's implemented in LabVIEW 2013.

If you make an array of 10 class A objects, and invoke a method M in a for loop, the same VI (class A:M.vi) get's called 10 times, and there will only be one instance of the re-entrant subVI inside that method that's called 10 times.

The result is [0,1,2,3,4,5,6,7,8,9], since the same instance of the PtByPt add is used. Not [0,0,0,0,0,0,0,0,0,0] because each object get's it's own PtByPt instance.

And I don't consider it a bug, just a reason to use PtByPt VI's in classes with caution.

[Intaris]

Nothing to do with lvoop. Notifiers behave the same because the callsites are being reused.  The reentrancy is per callsite not per object (or notifier reference).

[wiebe@CARYA]

Didn't say it had anything to do with lvoop. Just that PtByPt vi's can be used when you use the method then in an array of objects.

[AristosQueue (NI)]

I clearly misunderstood what you meant in your first post. With the picture, I get it. But then you say...

> And I don't consider it a bug, just a reason to use PtByPt

> VI's in classes with caution.

I don't see any reason for caution. The behavior is identical whether that VI is a member of a class or not a member of a class. The pt-by-pt state is method data, not object data. If you want to state it in C++ terms, this function...

int func(ClassName y) {

    static int x = 0;

    return ++x;

}

... works the same as this function...

int ClassName::func() {

    static int x = 0;

    return ++x;

}

... as shown here:

void main(void) {

     ClassName obj[] = { << array of 2 objects >> };

     int outOfClass = 0;

     int inClass = 0;

     for (int i = 0; i < 2; ++i) {

        outOfClass = func(obj[i]);

        inClass = obj[i]->func();

     }

     // Both inClass and outOfClass have the same value

     // at this point, even though the method was called

     // on two different objects. Method data is instanced

     // per method, not per object -- because it is method

     // data, not object data.

}

If C++ had the concept of reentrancy per call site , that x would still be cloned by call site, not by object reference used at the call site.

If it *didn't* have the same behavior inside vs outside the class, THAT would be a reason to have caution.

[AristosQueue (NI)]

(We are waaaaaaay off topic from this thread!)

[wiebe@CARYA]

It's still a bit on topic: the first solution\workaround offered (use a vi) is a valid solution, but may have side effects that are unexpected. A typical situation is the example I gave with objects. 

That example is biased by my preference for OO and indeed not exclusive to OO. 

Although that example could be considered an argument for the idea, I don't think it will happen anyway. But we'll see...

[wiebe@CARYA]

The reason for caution... Indeed more a reason why PtByPt vi's are not very useful in classes.

Let's' say you make a class that's controlling an output with a pid loop. Obviously you use the PtByPt vi, since it's there.

Now someone wants to control an array of outputs. The class won't work correctly, since there's only one instances of the PtByPt pid vi...

So using a PtByPt vi in a class limits the use of that class. It in a way exposes it's internals (use of a clone instance).

That's why AFAIC, PtByPt should be used with caution. The class works, and might pass tests, but if you use it the wrong way (in a for loop), results might be very wrong.

Since I like (the potential of) putting objects in an array, I usually end up rewriting the PtByPt vi's so there state isn't kept in shift registers, but in a separate class's private class data.