<div dir="ltr"><div>[... apologies if this is dup, got a bounce ...]</div><div><br></div><div dir="ltr">> [David Mertz <<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>>]<br>>> I have to say though that the existing behavior of `statistics.median[_low|_high|]`<br>>> is SURPRISING if not outright wrong.  It is the behavior in existing Python,<br>>> but it is very strange.<br>>><br>>> The implementation simply does whatever `sorted()` does, which is an<br>>> implementation detail.  In particular, NaN's being neither less than nor<br>>> greater than any floating point number, just stay where they are during<br>>> sorting.<br>> <br>> I expect you inferred that from staring at a handful of examples, but<br>> it's illusion.  Python's sort uses only __lt__ comparisons, and if<br>> those don't implement a total ordering then _nothing_ is defined about<br>> sort's result (beyond that it's some permutation of the original<br>> list).<br><br>Thanks Tim for clarifying.  Is it even the case that sorts are STABLE in<br>the face of non-total orderings under __lt__?  A couple quick examples<br>don't refute that, but what I tried was not very thorough, nor did I<br>think much about TimSort itself.<br><br>> So, certainly, if you want median to be predictable in the presence of<br>> NaNs, sort's behavior in the presence of NaNs can't be relied on in<br>> any respect.<br><br>Playing with Tim's examples, this suggests that statistics.median() is<br>simply outright WRONG.  I can think of absolutely no way to characterize<br>these as reasonable results:<br><br>Python 3.7.1 | packaged by conda-forge | (default, Nov 13 2018, 09:50:42)<br>In [4]: statistics.median([9, 9, 9, nan, 1, 2, 3, 4, 5])<br>Out[4]: 1<br>In [5]: statistics.median([9, 9, 9, nan, 1, 2, 3, 4])<br>Out[5]: nan<br></div></div>