will the first few iterations of the RNG be still divided by 5? this will give a lower average for the first few iterations. If you have some sort of true or false condition such as "if the average is lower than 5, then stop", then the system will often stop prematurely. How do you work around this?
In the while loop, you have access to the current iteration number. Since the edge case mentioned is true only for the first few iterations, specifically while the iteration number is less than the size of the moving average (5 in this case), you can hook up an if-conditional to divide by the iteration number when the iteration number is less than 5, and by 5 otherwise. You could make the wiring a bit simpler by taking a min value between the iteration number and the moving average size, which is an efficient shorthand for an upper limit. However, the moving average won't be of the same size for those elements, so the results you get are not consistent and, depending on your use case, they might be outright useless, so in general, it's best to calculate moving average only for the points where it makes sense and discard the edge cases.
WHERE'S VANEET
Well explained! It helped! Thank you!
will the first few iterations of the RNG be still divided by 5? this will give a lower average for the first few iterations. If you have some sort of true or false condition such as "if the average is lower than 5, then stop", then the system will often stop prematurely. How do you work around this?
In the while loop, you have access to the current iteration number. Since the edge case mentioned is true only for the first few iterations, specifically while the iteration number is less than the size of the moving average (5 in this case), you can hook up an if-conditional to divide by the iteration number when the iteration number is less than 5, and by 5 otherwise.
You could make the wiring a bit simpler by taking a min value between the iteration number and the moving average size, which is an efficient shorthand for an upper limit.
However, the moving average won't be of the same size for those elements, so the results you get are not consistent and, depending on your use case, they might be outright useless, so in general, it's best to calculate moving average only for the points where it makes sense and discard the edge cases.
Just curious, is this the best way to do a moving average?
Here is a forum post about doing a moving average in LabVIEW: forums.ni.com/t5/LabVIEW/Simple-Moving-Average-VI/td-p/3274490
Very nice but it seems the range of your random number generator is 0-10 not 1-10 as you stated at 0:30