zl.median bug or am I mis-using?
Hi, just discovered this:
I'm using zl.median to smooth out sensor values.
when I send a list of
[1,1,359,359]
I get an output of 180.
Is this the expected result? I thought median value had to be a member of the original list?
max 8.1.11
osx 11.6.5
If you have an even count of items you get the mean of the 2 center values after sorting. Try with 5 values and you get a member.
Ah thanks!
I can see how that's a difficult edge case. Not great for my application, but this gives me a hint for a workaround.
Wonder if it's worth mentioning in the help file?
it should offer three modes: "in case of stalemate output higher one, lower one, or the mean of the two candidates."
Wonder if it's worth mentioning in the help file?
I think not because that's what everybody expects from a median. Here's a custom solution that lets you get the lower or higher one.
one of the most mid values in a list is not less the central value of the list than a fictional, additional central value, which is not even part of the original list.
but i´ve looked it up, 11Olsen is right. that is how it is usually done and defined in math.
what is more important (than my unreasoned attempt to declare the median to have to be a list member) is why we measure the median and what are its properties. then it suddenly makes sense.
Thanks!
With a bit more research I see now that is the expected outcome. I didn't know that. And thanks for the proposed solution!
of course one problem remains: when you are in an integer-only world (such as midi note numbers), you might need to decide wether to round up or down in case the mean between the higher median and the lower median ends up beeing 117.5