Dennis Sweeney <sweeney.dennis...@gmail.com> added the comment:
This is essentially the same issue, but with sorted(): https://bugs.python.org/issue36095 The trouble is that the implementation of min() is roughly equivalent to: iterable = iter(iterable) current_min = next(iterable) for x in iterable: if x < current_min: current_min = x return current_min NaN < number and number < NaN both return false. Thus including NaNs make floats not totally ordered, so there's no perfect way to sort them or take a max/min. This leads to some unexpected result, as you've identified. So you could say that the real "bug" is in floats more broadly. This behavior was originally implemented to comply with IEEE 754. Even if that was a mistake, it would be very difficult to change this behavior in case someone's code relies on exactly using this implantation. I also don't like the idea of special-casing the behavior of min/max for floats, since right now the behavior is completely agnostic of the types of the items. ---------- nosy: +Dennis Sweeney _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44370> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
