[issue19161] collections Counter handles nan strangely

Changes by Raymond Hettinger : -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue19161] collections Counter handles nan strangely

Terry J. Reedy added the comment: This is the sort of issue that makes me think that there should be a single nan object (perhaps an instance of a Nan(float) subclass with a special __eq__ method ;-). Pending that, I agree with closing as "won't fix". -- nosy: +terry.reedy ___

[issue19161] collections Counter handles nan strangely

Mark Dickinson added the comment: > perhaps collections.Counter should handle nans as a special case I don't think that would be a good idea: I'd rather that collections.Counter didn't special case NaNs in any way, but instead treated NaNs following the same (admittedly somewhat awkward) rule

[issue19161] collections Counter handles nan strangely

Adam Davison added the comment: Thanks for the quick response. I'm really using a pandas Series, which is effectively a numpy array behind the scenes as far as I understand, the example I pasted was just to illustrate the behaviour. So the nans are being produced elsewhere, I don't really have

[issue19161] collections Counter handles nan strangely

Mark Dickinson added the comment: > Presumably this relates to the fact that nan != nan. Yep. What you're seeing is pretty much expected behaviour, and it matches how NaNs behave with respect to containment in other Python contexts: >>> x = float('nan') >>> y = float('nan') >>> s = {x} >>> x

[issue19161] collections Counter handles nan strangely

New submission from Adam Davison: If you pass an array containing nan to collections.Counter, rather than counting the number of 'nan's it outputs "'nan': 1" n times into the dictionary. I appreciate using this on an array of floats is a bit of an unusual case but I don't think this is the exp