On Fri, 2023-04-21 at 17:16 +0200, Benjamin Beichler wrote: > > > > So then we could say we'll just fix them, but what value actually makes > > sense to init with? You don't necessarily know, right? Initially biasing > > towards the first value makes a lot more sense than initially biasing > > towards zero, no? And then if you want to achieve that, now you have to > > either use _add_or_init(), which is probably what people will do, but > > that continues having the problem ... > > I left out the the individual fixes for users, but for the samples I > looked into, either start values were given, or they were semantically > extractable. > > e.g. virtios pkt_len ewma is clamped anyways, so using the clamp border > or in between will be safe. > > Most others are signals-strengths, many of them also only for > statistics, where a slow convergence is okay in my opinion. Yeah I guess that's the thing, we can accept slower convergence in many cases, and "safe" start values mean that mostly. But why accept it when we don't have to? > IMHO the net improvement is, that if you do not use the convenience > add_or_init function, it simply resembles the ewma filter of a math or > CS-textbook. Not sure I see that as a good argument. The practical engineering side tends to always be more complex than the theory, and that's not really unexpected. We can comment why it's different :-) > The original problem was, that the ewma had a surprising > output in a special situation. Right, but that's an implementation issue, because we thought 0 == uninit was clever, without realizing the corner case. > But while writing the commit, I recognized, that the current ewma > implementation is only for unsigned values, which means the problem > really only happens for many consecutive 0 values. I try to think over, > what this means for the proposal of Felix, but I'm not able to think > about unsigned C-arithmetics today :-D Not much really, I think? It eases thinking about it though :) > If we use that fix, then we should have an additional compile time > check, that the precision has at least 2 or 4 bits, to really avoid the > problem, shouldn't we? Yes. I think 1 bit is enough, but yes, it can't be 0 bits. johannes
