LabVIEW
Averaging of each element of array
Solved!
@altenbach wrote:Note that this is very efficient because it just maintains the sum and adds the new values while subtracting the oldest.
However, the sum can get corrupted, not just by NaN, Inf and -Inf, but also by (relative) large (positive or negative) numbers:
10E23 + 1.0 + -10E23 != 1.0
I've found where I needed moving averaging, guarding for NaN, Inf and -Inf made things slower than simply keeping a history and averring it. And that also solves the range problem.
There will be a break even point, but for averages of up to a few k samples, the naïve method isn't worse than a sophisticated method with protection against NaN, Inf and -Inf.
Of course, if the signal doesn't get NaN, Inf, Inf or has a large range of values, keeping the sum is more efficient.
Search LabVIEW like a graph! 
Race Condition
Followed by the wrong (bugged) version of Means PtbtPt.vi
Delete the previous Means PtbyPt.vi which autoindexed the uninitialized Feedback loop. Use the attached vis backsaved to 2015
Not sure why you wouldn't use a circular buffer with a pointer (as suggested in the 3rd reply).
A rotate and replace is going to be slower than it needs to be.
wiebe@CARYA wrote:
There will be a break even point, but for averages of up to a few k samples, the naïve method isn't worse than a sophisticated method with protection against NaN, Inf and -Inf.
Of course, if the signal doesn't get NaN, Inf, Inf or has a large range of values, keeping the sum is more efficient.
Yes, of course. Good point. It would be trivial to eliminate the running sum and do the averaging with each iteration. Both versions are described in my talk, of course.
Typically, data from an instruments will be well quantized and based on FXP (12 bits .. 16bits?) and thus will fit into a DBL with bits to spare. Of course if this runs for years at GHz, truncation errors will eventually start to accumulate. 😄
@JÞB wrote:
@altenbach wrote:
(I am not going to troubleshoot an unknown, untested subVI, but maybe it is buggy.)From anyone else I'd take offense 😄
It was more of a time issue. I just looked at the picture and thought it was loosely based on the stock scalar ptbypt mean, but I did not inspect it in detail because I already had code that basically does the same with less and more "in-place" (sure hate those "insert into array thingies" I saw 😄 ). All I know was that it did not work so I though the original author would be better suited to look into it.
@JÞB wrote:
@altenbach wrote:
@JÞB wrote:
@altenbach wrote:
(I am not going to troubleshoot an unknown, untested subVI, but maybe it is buggy.)From anyone else I'd take offense 😄
It was more of a time issue. I just looked at the picture and thought it was loosely based on the stock scalar ptbypt mean, but I did not inspect it in detail because I already had code that basically does the same with less and more "in-place" (sure hate those "insert into array thingies" I saw 😄 ). All I know was that it did not work so I though the original author would be better suited to look into it.
Absolutely and totally adapted from the original PtbyPt vi. I would have used a circular buffer myself and prepended the build Array.
Prepending is also slow. If you want some speed, the buffer needs to be circular, and the data shouldn't be moved..
Alternatively, you can double the buffer in size, and replace new samples in two locations (index and index + size). Now you can always get all ordered samples fast. At the expense of slower writes and more memory.
@JÞB wrote:
Some of the cases are not worthy of mention EXCEPT on the Rube-Goldburg thread! but it does protect against inf and nan.
Don't forget about the big vs small numbers! They are just as bad as NaN and (-)Inf, only even more overlooked.
wiebe@CARYA wrote:
@JÞB wrote:
Some of the cases are not worthy of mention EXCEPT on the Rube-Goldburg thread! but it does protect against inf and nan.Don't forget about the big vs small numbers! They are just as bad as NaN and (-)Inf, only even more overlooked.
As I said, this is probably not an issue with measurement data where even a 24 bit analog input has manageable range between smallest and largest. Personally, I still like the exponential filter alternative where really old data simply disappears below epsilon anyway. (Still needs to be protected from NaN and Infs, not shown in my code)
