Talk:Averages/Simple moving average
Numerical soundness
The implementations which use or permit floats and keep a running sum which is added to and subtracted from, if given nontrivial numbers, will eventually have the sum drift away from the actual value because floating-point arithmetic is nonassociative ((((a + b) + c) + d) - a is not necessarily equal to (((a - a) + b) + c) + d = (b + c) + d); should this be considered incorrect, or warned about? --Kevin Reid 14:51, 20 June 2009 (UTC)
- Hmm, and wouldn't it potentially loose less precision if you sorted on absolute values and summed from the smallest absolute value up? We could hope that people read the talk page before using code snippets? --Paddy3118 16:07, 20 June 2009 (UTC)
- I suppose in a "moving average" you can't sort operands, unless you store them, and doing so has not so good implications. I suppose also that investigating the limits of IEEE floating point is not the focus of the task. Users run code on RC at their own risk! --ShinTakezou 15:27, 21 June 2009 (UTC)
- Rosetta Code is not a code snippet repository; Code snippets shouldn't be placed here under the expectation that someone will use them verbatim. Pointing out the implications of floating-point error (or any other error caused by underlying tools) as it relates to the task or problem area is well within the educational nature of the site, and is a reasonable thing to do when notice to avoid harming people who use the code without sufficiently understanding what it does. --Short Circuit 19:36, 21 June 2009 (UTC)
- Of course, it's worth noting. (And by "you can't sort operands..." I meant "you can't sort all the operands, unless you store them all" of course...:D) --ShinTakezou 23:01, 22 June 2009 (UTC)
- If you're only maintaining the last values, sorting isn't such a big issue and the size of the error is likely to remain small (a few ULP in the result if all values are positive, not a problem if they are all of the same sort of magnitude). However, it does require keeping those values around and recalculating the sum each time rather than adding and subtracting from a running total. Not very onerous for . In fact, it's only really a problem for people who are being too clever by half… –Donal Fellows 06:35, 6 February 2010 (UTC)
- Of course, it's worth noting. (And by "you can't sort operands..." I meant "you can't sort all the operands, unless you store them all" of course...:D) --ShinTakezou 23:01, 22 June 2009 (UTC)
- Rosetta Code is not a code snippet repository; Code snippets shouldn't be placed here under the expectation that someone will use them verbatim. Pointing out the implications of floating-point error (or any other error caused by underlying tools) as it relates to the task or problem area is well within the educational nature of the site, and is a reasonable thing to do when notice to avoid harming people who use the code without sufficiently understanding what it does. --Short Circuit 19:36, 21 June 2009 (UTC)
- I suppose in a "moving average" you can't sort operands, unless you store them, and doing so has not so good implications. I suppose also that investigating the limits of IEEE floating point is not the focus of the task. Users run code on RC at their own risk! --ShinTakezou 15:27, 21 June 2009 (UTC)
Autohotkey takes average of all previous
-Ut should be a sum of the last N items, not all previous items. --Paddy3118 04:02, 22 June 2009 (UTC)
Lua problem
The lus entry haas a problem. A moving average is of the last N items if N is 5 for example then it is an averaage of the last (no more than) 5 items. When a sixth item comes along you must drop the first and average the last five, i.e. the second to the sixth items. I was going to say check the wp link given, but it seems to be obfuscated by its terminology - oh well. --Paddy3118 06:40, 5 February 2010 (UTC)