[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Raymond Hettinger added the comment: Closing for the reasons listed and also because there is another pair of tracker items 22000 and 22001 pursuing related documentation updates. -- resolution: -> not a bug status: open -> closed ___ Python tracker

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Changes by Andy Maier : -- nosy: +andymaier ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Raymond Hettinger added the comment: I think this should be closed. AFAICT it is of interest to a very tiny subset of the human species and as near as I can tell that subset doesn't include people in the numeric and statistics community (the ones who actually use NaNs as placeholders for miss

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Changes by Terry J. Reedy : -- versions: +Python 3.4 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Nick Coghlan added the comment: Scratch the first half of that last comment - Guido pointed out that false positives rear their ugly head almost immediately if you try to store rich comparison objects in other containers. -- ___ Python tracker

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Nick Coghlan added the comment: After further discussion on python-dev, it is clear that this identity checking behaviour handles more than just NaNs - it also allows containers to cope more gracefully with objects like NumPy arrays that make use of rich comparisons to return something other

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Terry J. Reedy added the comment: To repeat concisely what I said on pydev list, I think Reference 5.9. Comparisons, which says "Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and t

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Alexander Belopolsky added the comment: On Thu, Apr 28, 2011 at 3:26 AM, Nick Coghlan wrote: .. > 1. Write fully conformant implementations of IEEE754 floating point types, > including the non-reflexive NaN comparisons > (keeping in mind that, as a value-based specification, "same payload" is

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Glenn Linderman added the comment: Nick says (and later explains better what he meant): The status quo works. Proposals to change it on theoretical grounds have a significantly higher bar to meet than proposals to simply document it clearly. I say: What the status quo doesn't provide is conta

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Nick Coghlan added the comment: By "works" I merely meant that you can currently achieve both of the following: 1. Write fully conformant implementations of IEEE754 floating point types, including the non-reflexive NaN comparisons (keeping in mind that, as a value-based specification, "same p

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Alexander Belopolsky added the comment: On Thu, Apr 28, 2011 at 3:01 AM, Nick Coghlan wrote: .. > The status quo works. No it does not. I am yet to see a Python program that uses non-reflexivity of NaN in a meaningful way. What I've seen was either programmers ignore it and write slightly bug

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Changes by Raymond Hettinger : -- assignee: docs@python -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list ma

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Nick Coghlan added the comment: The status quo works. Proposals to change it on theoretical grounds have a significantly higher bar to meet than proposals to simply document it clearly. -- ___ Python tracker

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Alexander Belopolsky added the comment: > I think it is presently a bug that a list containing > a NaN value compares equal to itself. Moreover, it also compares equal to another list containing the same NaN: >>> [nan] is [nan] False >>> [nan] == [nan] True Here is another case of is implies

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Glenn Linderman added the comment: Bertrand Meyer's exposition is flowery, and he is a learned man, but the basic argument he makes is: Reflexivity of equality is something that we expect for any data type, and it seems hard to justify that a value is not equal to itself. As to assignment,

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

Nick Coghlan added the comment: Actually, based on the NumPy precedent [1], array.array should be fine as is. Since it uses raw C floats and doubles internally, rather than Python objects, there is no clear concept of "object identity" to use to enforce reflexivity. [1] http://mail.python.org

[issue11945] Adopt and document consistent semantics for handling NaN values in containers

New submission from Nick Coghlan : The question of the way Python handles NaN came up again on python-dev recently. The current semantics have been assessed as a reasonable compromise, but a poorly explained and inconsistently implemented one. Based on a suggestion from Terry Reedy [1] I propo