Am 21.04.2023 um 13:13 schrieb Johannes Berg:
________________________________
Achtung! Externe E-Mail: Klicken Sie erst dann auf Links und Anhänge, nachdem Sie die Vertrauenswürdigkeit der Absenderadresse geprüft haben.
________________________________
On Fri, 2023-04-21 at 12:34 +0200, Benjamin Beichler wrote:
So then let's say we want to fix the existing code. I can think of these
possible ways:
* splitting off a bit for initialized from the unsigned long
(which at least for 64-bit should be OK since presumably most code
using this will run on 32-bit systems too)
* adding another value for it, e.g. making it u32 and adding a bool
for
"first value"
* biasing the value, like Felix proposes, could be by 1 or -1 for
example
You forgot the possibility to introduce a separate init function, which
boils down to a shift with an assignment statement for code, and no
further data memory cost. Even simply extending the current init
function (which simply always set 0) would be enough.
Sort of. Yeah I should've mentioned it, but that means you actually have
to know the first value, and track "first time usage" separately in the
user code.
Or you init to something useful at the first value, e.g. saying for
signal strength "let's assume -45dBm average if we don't know". That
doesn't seem very practical?
I think (at least for the usages I dig into), either those values are
already defined and applied with a bogus *_add.
The behaviour of "first value inserted will init" seems sensible.
Okay, my suggestion, as this is a c-macro version, which is generated
for each user: why not offer both? If it is unused, the compiler will
sort that out. Then we simply keep the zero as special value for init
(and document it) and otherwise for the more mathematically defined
usage. But my feeling is, that most users do not care about the first
values that much and wait to let the ewma settle to some value.
I try to do a RFC patch, with what I mean.
Benjamin
