Re: [RFC v2] average: rewrite for clearity

[Johannes Berg <johannes@sipsolutions.net>]

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