Actually by trying to force the EMA value to integers (I just changed the EMA to use "4" instead of "5" and left the rest the same, I can confirm that, on my computer, at least, the second run is definitely due to FP errors. The problem is that I do not clearly see why they are occuring. And given that the problem seems non-existent if we force a recreation of the EMA class instance by first disposing of it, I must conclude that something really is, as you say, wonky.
Here is my output when I change the period to 4. I do expect the first term of the EMA to be exactly 260, and the other to be exactly 100, according to the universally accepted method of calculating an EMA (using 2 terms).
------------------------- VALUE: 500 EMA: 260 VALUE: 100 EMA: 100 VALUE: 100 EMA: 100 VALUE: 100 EMA: 100 VALUE: 100 EMA: 100 ------------------------- VALUE: 500 EMA: 260.000000000008 VALUE: 100 EMA: 100.000000000013 VALUE: 100 EMA: 100.000000000022 VALUE: 100 EMA: 100.000000000036 VALUE: 100 EMA: 100.00000000006
Comment