<div dir="ltr"><div>I have to say though that the existing behavior of `statistics.median[_low|_high|]` is SURPRISING if not outright wrong.  It is the behavior in existing Python, but it is very strange.</div><div><br></div><div>The implementation simply does whatever `sorted()` does, which is an implementation detail.  In particular, NaN's being neither less than nor greater than any floating point number, just stay where they are during sorting.  But that's a particular feature of TimSort.  Yes, we are guaranteed that sorts are stable; and we have rules about which things can and cannot be compared for inequality at all.  But beyond that, I do not think Python ever promised that NaNs would remain in the same positions after sorting if some other position was stable under a different sorting algorithm.</div><div><br></div><div>So in the incredibly unlikely even I invent a DavidSort that behaves better than TimSort, is stable, and compares only the same Python objects as current CPython, a future version could use this algorithm without breaking promises... even if NaN's sometimes sorted differently than in TimSort.  For that matter, some new implementation could use my not-nearly-as-good DavidSort, and while being slower, would still be compliant.</div><div><br></div><div>Relying on that for the result of `median()` feels strange to me.  It feels strange as the default behavior, but that's the status quo.  But it feels even stranger that there are not at least options to deal with NaNs in more of the signaling or poisoning ways that every other numeric library does.</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 6, 2019 at 7:28 PM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bug #33084 reports that the statistics library calculates median and <br>
other stats wrongly if the data contains NANs. Worse, the result depends <br>
on the initial placement of the NAN:<br>
<br>
py> from statistics import median<br>
py> NAN = float('nan')<br>
py> median([NAN, 1, 2, 3, 4])<br>
2<br>
py> median([1, 2, 3, 4, NAN])<br>
3<br>
<br>
See the bug report for more detail:<br>
<br>
<a href="https://bugs.python.org/issue33084" rel="noreferrer" target="_blank">https://bugs.python.org/issue33084</a><br>
<br>
<br>
The caller can always filter NANs out of their own data, but following <br>
the lead of some other stats packages, I propose a standard way for the <br>
statistics module to do so. I hope this will be uncontroversial (he <br>
says, optimistically...) but just in case, here is some prior art:<br>
<br>
(1) Nearly all R stats functions take a "na.rm" argument which defaults <br>
to False; if True, NA and NAN values will be stripped.<br>
<br>
(2) The scipy.stats.ttest_ind function takes a "nan_policy" argument <br>
which specifies what to do if a NAN is seen in the data.<br>
<br>
<a href="https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html" rel="noreferrer" target="_blank">https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.ttest_ind.html</a><br>
<br>
(3) At least some Matlab functions, such as mean(), take an optional <br>
flag that determines whether to ignore NANs or include them.<br>
<br>
<a href="https://au.mathworks.com/help/matlab/ref/mean.html#bt5b82t-1-nanflag" rel="noreferrer" target="_blank">https://au.mathworks.com/help/matlab/ref/mean.html#bt5b82t-1-nanflag</a><br>
<br>
<br>
I propose adding a "nan_policy" keyword-only parameter to the relevant <br>
statistics functions (mean, median, variance etc), and defining the <br>
following policies:<br>
<br>
    IGNORE:  quietly ignore all NANs<br>
    FAIL:  raise an exception if any NAN is seen in the data<br>
    PASS:  pass NANs through unchanged (the default)<br>
    RETURN:  return a NAN if any NAN is seen in the data<br>
    WARN:  ignore all NANs but raise a warning if one is seen<br>
<br>
PASS is equivalent to saying that you, the caller, have taken full <br>
responsibility for filtering out NANs and there's no need for the <br>
function to slow down processing by doing so again. Either that, or you <br>
want the current implementation-dependent behaviour.<br>
<br>
FAIL is equivalent to treating all NANs as "signalling NANs". The <br>
presence of a NAN is an error.<br>
<br>
RETURN is equivalent to "NAN poisoning" -- the presence of a NAN in a <br>
calculation causes it to return a NAN, allowing NANs to propogate <br>
through multiple calculations.<br>
<br>
IGNORE and WARN are the same, except IGNORE is silent and WARN raises a <br>
warning.<br>
<br>
Questions:<br>
<br>
- does anyone have an serious objections to this?<br>
<br>
- what do you think of the names for the policies?<br>
<br>
- are there any additional policies that you would like to see? <br>
  (if so, please give use-cases)<br>
<br>
- are you happy with the default?<br>
<br>
<br>
Bike-shed away!<br>
<br>
<br>
<br>
-- <br>
Steve<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons.  Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div></div>