Re: Can one output something other than 'nan' for not a number values?

On 20/02/24 01:04, Chris Green via Python-list wrote: dn wrote: On 18/02/24 09:53, Grant Edwards via Python-list wrote: On 2024-02-17, Cameron Simpson via Python-list wrote: On 16Feb2024 22:12, Chris Green wrote: I'm looking for a simple way to make NaN values output as something like

Re: Can one output something other than 'nan' for not a number values?

On 20/02/24 05:58, Grant Edwards via Python-list wrote: Here's a demonstration of how to hook custom code into the f-string formatting engine. It's brilliantly depraved. https://stackoverflow.com/questions/55876683/hook-into-the-builtin-python-f-string-format-machinery From the above:

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-19, Chris Green via Python-list wrote: > It's using f'{...}' at the moment. Here's a demonstration of how to hook custom code into the f-string formatting engine. It's brilliantly depraved.

Re: Can one output something other than 'nan' for not a number values?

Grant Edwards wrote: > On 2024-02-16, Chris Green via Python-list wrote: > > > I'm looking for a simple way to make NaN values output as something > > like '-' or even just a space instead of the string 'nan'. > > It would probably help if you told us how you'

Re: Can one output something other than 'nan' for not a number values?

dn wrote: > On 18/02/24 09:53, Grant Edwards via Python-list wrote: > > On 2024-02-17, Cameron Simpson via Python-list > > wrote: > >> On 16Feb2024 22:12, Chris Green wrote: > >>> I'm looking for a simple way to make NaN values output as something > &g

Re: Can one output something other than 'nan' for not a number values?

On 18/02/24 09:53, Grant Edwards via Python-list wrote: On 2024-02-17, Cameron Simpson via Python-list wrote: On 16Feb2024 22:12, Chris Green wrote: I'm looking for a simple way to make NaN values output as something like '-' or even just a space instead of the string 'nan

Re: Can one output something other than 'nan' for not a number values?

On Mon, 19 Feb 2024 at 06:47, Grant Edwards via Python-list wrote: > I would be tempted to try monkey-patching the float class to override > the __format__ method. I have no idea what side effects that might > have, or if it's even used by the various formatting mechanisms, so > you might end up

Re: Can one output something other than 'nan' for not a number values?

On 16/02/2024 23.12, Chris Green wrote: I'm looking for a simple way to make NaN values output as something like '-' or even just a space instead of the string 'nan'. This would then make it much easier to handle outputting values from sensors when not all sensors are present. So, for example

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-16, Chris Green wrote: > I'm looking for a simple way to make NaN values output as something > like '-' or even just a space instead of the string 'nan'. I tried monkey-patching the __format__ method of float, but it's immutable, so that didnt' work. Is float.__format__ what'

Can one output something other than 'nan' for not a number values?

[I've been trying all afternoon to post via slrn, but nothing is showing up on the list. Forgive me if multiple posts eventually show up.] On 2024-02-17, Cameron Simpson via Python-list wrote: > On 16Feb2024 22:12, Chris Green wrote: >>I'm looking for a simple way to make NaN valu

Can one output something other than 'nan' for not a number values?

[Posts via slrn and my GMail account aren't showing up, so I guess I'll try subscribing from a different e-mail address.] On 2024-02-17, Cameron Simpson via Python-list wrote: On 16Feb2024 22:12, Chris Green wrote: I'm looking for a simple way to make NaN values output as something like

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-17, Cameron Simpson via Python-list wrote: > On 16Feb2024 22:12, Chris Green wrote: >>I'm looking for a simple way to make NaN values output as something >>like '-' or even just a space instead of the string 'nan'. [...] >> >>Battery Voltages and Cur

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-17, Cameron Simpson via Python-list wrote: > On 16Feb2024 22:12, Chris Green wrote: >>I'm looking for a simple way to make NaN values output as something >>like '-' or even just a space instead of the string 'nan'. [...] >> >>Battery Voltages and Cur

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-17, Cameron Simpson via Python-list wrote: > On 16Feb2024 22:12, Chris Green wrote: >>I'm looking for a simple way to make NaN values output as something >>like '-' or even just a space instead of the string 'nan'. [...] >> >>Battery Voltages and Cur

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-17, Cameron Simpson via Python-list wrote: > On 16Feb2024 22:12, Chris Green wrote: >>I'm looking for a simple way to make NaN values output as something >>like '-' or even just a space instead of the string 'nan'. >>[...] >> >>Battery Voltages a

Re: Can one output something other than 'nan' for not a number values?

On 2024-02-16, Chris Green via Python-list wrote: > I'm looking for a simple way to make NaN values output as something > like '-' or even just a space instead of the string 'nan'. It would probably help if you told us how you're "outputting" them now (the Python feaature

Re: Can one output something other than 'nan' for not a number values?

On 16Feb2024 22:12, Chris Green wrote: I'm looking for a simple way to make NaN values output as something like '-' or even just a space instead of the string 'nan'. This would then make it much easier to handle outputting values from sensors when not all sensors are present. So, for example

Can one output something other than 'nan' for not a number values?

I'm looking for a simple way to make NaN values output as something like '-' or even just a space instead of the string 'nan'. This would then make it much easier to handle outputting values from sensors when not all sensors are present. So, for example, my battery monitoring program outputs

[issue47020] float('nan')==math.nan does NOT evaluate to True (as suggested by documentation).

Eric V. Smith added the comment: Jelle gives the correct reason for what you're seeing. Also note: >>> math.nan == math.nan False >>> float('nan') == float('nan') False If there's some specific part of the documentation that you think is misleading, please reopen

[issue47020] float('nan')==math.nan does NOT evaluate to True (as suggested by documentation).

Jelle Zijlstra added the comment: I'm guessing you're referring to https://docs.python.org/3.8/library/math.html#math.nan. The text says explicitly that math.nan is "equivalent" to float("nan"), not that it is equal. This is correct. nan is not equal to itself, because

[issue47020] float('nan')==math.nan does NOT evaluate to True (as suggested by documentation).

New submission from Pablo Dumas : float('nan')==math.nan does NOT evaluate to True (as suggested by documentation). On the other hand, float('inf')==math.inf DOES evaluate to True (as suggested by documentation). Documentation we're referring to: https://docs.python.org/3.8/library

[issue46656] Remove the Py_NO_NAN macro: require NAN to build Python 3.11

STINNER Victor added the comment: > bpo-46656: Remove Py_NO_NAN macro (GH-31160) Change documented by: New changeset 7854012077009b9f364f198a8ae38b546ec58313 by Victor Stinner in branch 'main': bpo-46917: math.nan is now always available (GH-31793)

[issue46640] Python can now use the C99 NAN constant or __builtin_nan()

STINNER Victor added the comment: PEP 7 has been updated, I close the issue. -- status: open -> closed ___ Python tracker ___ ___

[issue46656] Remove the Py_NO_NAN macro: require NAN to build Python 3.11

Change by STINNER Victor : -- components: +Build, Interpreter Core resolution: -> fixed stage: patch review -> resolved status: open -> closed title: Compile fails if Py_NO_NAN is defined -> Remove the Py_NO_NAN macro: require NAN to build Python 3.11 versions: -Python

[issue46640] Python can now use the C99 NAN constant or __builtin_nan()

Petr Viktorin added the comment: > IMO this PEP is outdated for a long time. It is not. Even if it is, it should be marked as such, and that is not a decision that should be done in this issue. Please, don't break the rules because you think they're outdated. > Well, if you ask me, I would

[issue46640] Python can now use the C99 NAN constant or __builtin_nan()

STINNER Victor added the comment: > Well, if you ask me, I would simply require a C99 compiler. That's all :-) Done in https://github.com/python/peps/pull/2309 -- ___ Python tracker

[issue46640] Python can now use the C99 NAN constant or __builtin_nan()

STINNER Victor added the comment: > Adding new C99 features needs a change in PEP 7 > (https://www.python.org/dev/peps/pep-0007/#c-dialect) IMO this PEP is outdated for a long time. C99 standard is wide. Do we have to explicitly list every single function, macro or constant used by Python?

[issue46640] Python can now use the C99 NAN constant or __builtin_nan()

Petr Viktorin added the comment: Adding new C99 features needs a change in PEP 7 (https://www.python.org/dev/peps/pep-0007/#c-dialect) -- nosy: +petr.viktorin status: closed -> open ___ Python tracker

[issue46640] Python can now use the C99 NAN constant or __builtin_nan()

STINNER Victor added the comment: I merged my change, thanks for the reviews. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: Python can now use the C99 NAN constant -> Python can now use the C99 NAN constant or _

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: New changeset 54842e4311bb0e34012d1984b42eab41eeeaea6a by Victor Stinner in branch 'main': bpo-46640: Py_NAN now uses the C99 NAN constant (GH-31134) https://github.com/python/cpython/commit/54842e4311bb0e34012d1984b42eab41eeeaea6a

[issue46640] Python can now use the C99 NAN constant

Mark Dickinson added the comment: > If a platform doesn't implement NaN, it should define the Py_NO_NAN macro Ah. In that case your PR description (and the PR news entry) is misleading: > Building Python now requires a C99 header file providing the > NAN constant. Please could y

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: > The big blocker here is that a platform that fully supports C99 might not > define the "NAN" macro. I don't think we can require that NAN be defined in > order for Python to build (which is what the PR currently does, if I'm > unde

[issue46640] Python can now use the C99 NAN constant

Mark Dickinson added the comment: The big blocker here is that a platform that fully supports C99 might not define the "NAN" macro. I don't think we can require that NAN be defined in order for Python to build (which is what the PR currently does, if I'm understanding it correctly

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: Using clang -E, I see that clang also replaces NAN with: __builtin_nanf (""). -- ___ Python tracker <https://bugs.python.o

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: > see attached script: test_nan_bits.py test_nan_bits.py says "True" for Python built with "clang -O3" and with "clang -O0". -- ___ Python tracker

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: Python/dtoa.c uses: /* Standard NaN used by _Py_dg_stdnan. */ #define NAN_WORD0 0x7ff8 #define NAN_WORD1 0 /* Return a 'standard' NaN value. There are exactly two quiet NaNs that don't arise by 'quieting' signaling NaNs (see IEEE 754-2008

[issue46640] Python can now use the C99 NAN constant

86_64. I tested with "gcc -O0" and "gcc -O3". GCC float.h defines NAN with: #define NAN (__builtin_nanf ("")) GCC: "Built-in Function: double __builtin_nan (const char *str): This is an implementation of the ISO C99 function nan." -- Added file:

[issue46640] Python can now use the C99 NAN constant

STINNER Victor added the comment: > mathmodule.c and cmathmodule.c m_nan() still use _Py_dg_stdnan() by default > (if PY_NO_SHORT_FLOAT_REPR is not defined). These functions are only use to create the following constants: * math.nan * cmath.nan * cmath.nanj --

[issue46640] Python can now use the C99 NAN constant

#21167: Fix definition of NAN when ICC used without -fp-model strict. Patch from Chris Hogan of Intel, reviewed by Mark Dickinson. --- I don't know if it should be kept if Py_NAN is modified to use the NAN constant. In case of doubt, I prefer to remove the ICC code since we have no ICC

[issue46640] Python can now use the C99 NAN constant

Change by STINNER Victor : -- keywords: +patch pull_requests: +29313 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31134 ___ Python tracker ___

[issue46640] Python can now use the C99 NAN constant

New submission from STINNER Victor : While debugging a GCC regression (*) on "HUGE_VAL * 0" used by Py_NAN macro, I noticed that Python can now C99 "NAN" constant. (*) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104389 In bpo-45440, I already removed legacy code for pre

[issue43475] Worst-case behaviour of hash collision with float NaN

Christoph Groth added the comment: > What concrete action would you propose that the Python core devs take at this > point? Nothing for now. I stumbled across this issue through https://gitlab.kwant-project.org/kwant/tinyarray/-/issues/20 and had the impression that the aspect that I

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: Just for fun: I gave a somewhat ranty 10-minute talk on this topic at a (virtual) conference a few months ago: https://www.youtube.com/watch?v=01oeosRVwgY -- ___ Python tracker

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: @cwg: Yep, we're aware of this. There are no good solutions here - only a mass of constraints, compromises and trade-offs. I think we're already somewhere on the Pareto boundary of the "best we can do" given the constraints. Moving to another point on the

[issue43475] Worst-case behaviour of hash collision with float NaN

Christoph Groth added the comment: Hello. I would like to point out a possible problem that this change to CPython has introduced. This change looks innocent, but it breaks the unwritten rule that the hash value of a number (or actually any built-in immutable type!) in Python depends only

[issue33084] statistics module: NaN handling in median, median_high an median_low

Steven D'Aprano added the comment: See thread on Python-Ideas. https://mail.python.org/archives/list/python-id...@python.org/thread/EDRF2NR4UOYMSKE64KDI2SWUMKPAJ3YM/ -- ___ Python tracker

[issue45032] struct.unpack() returns NaN

Terry J. Reedy added the comment: Jorge, next time you have questions about how to use a module (and struct is fairly advanced), please ask on an appropriate forum, such as python-list. Then Steven's nice answer could be read by 100s of people instead of likely less than 10. I looked as

[issue45032] struct.unpack() returns NaN

Steven D'Aprano added the comment: This is not a bug, and I'm unconvinced that it needs a documentation change. If you are using struct to assemble values, you need to know the meaning of the struct format. It returns a float NAN because you give it the bit pattern of a NAN. For C singles

[issue45032] struct.unpack() returns NaN

is not in a suitable position I think. Applying big-endian to the format, it returns a numeric value, but being little-endian it returns a NaN. > struct.unpack(' struct.unpack('>f', struct.pack('HH',0, 32704)) Out[169]: (6.905458702346266e-41,) The current documentation on struct.unpack doesn't an

[issue14613] time.time can return NaN

Mark Dickinson added the comment: > I propose we close it [...] Seconded! -- stage: test needed -> resolved status: pending -> closed ___ Python tracker ___

[issue14613] time.time can return NaN

Irit Katriel added the comment: The versions field includes 3.2 and 3.3, but from the discussion it seems the problem was only observed in 2.7, and went away after a third party upgrade. It seems unlikely that we will be ably to make more progress on this issue. I propose we close it and

[issue33084] statistics module: NaN handling in median, median_high an median_low

Raymond Hettinger added the comment: [Steven] > Thoughts? 1) Document that results are undefined if a NaN is present in the data. 2) Add function to strip NaNs from the data: def remove_nans(iterable): "Remove float('NaN') and other objects not equal to th

[issue33084] statistics module: NaN handling in median, median_high an median_low

-- nosy: +iritkatriel title: Computing median, median_high an median_low in statistics library -> statistics module: NaN handling in median, median_high an median_low versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.8 __

[issue44770] float('nan') is True

Tim Peters added the comment: Sorry, I'm just going to close this. For values of all numeric types now, `bool(x)` returns the same as `x != type(x)(0)`. Besides being backward-incompatible, making an exception for NaN would be jarringly inconsistent. Note that you don't need numpy

[issue44770] float('nan') is True

benefit from a clarifying comment like if x: # check for NaNs ... ...so that is a hint to me that using the existing math.isnan() (or numpy.isnan() if you have numpy) is more explicit and therefore more readable. I also think it would be confusing to have two different floats (0.0 and NaN

[issue44770] float('nan') is True

New submission from Marty : I know that there is numpy.isnan() for checking if a value is float('nan') but I think that native python should logically return False in bool(float('nan')). -- messages: 398448 nosy: vpjtqwv0101 priority: normal severity: normal status: open title: float

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: I think this can be closed now. -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: New changeset 8d0b2ca493e236fcad8709a622c1ac8ad29c372d by Mark Dickinson in branch '3.10': [3.10] bpo-43475: Add what's new entry for NaN hash changes (GH-26725) (GH-26743) https://github.com/python/cpython/commit/8d0b2ca493e236fcad8709a622c1ac8ad29c372d

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Mark Dickinson : -- pull_requests: +25328 pull_request: https://github.com/python/cpython/pull/26743 ___ Python tracker ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: New changeset 1d10bf0bb9409a406c56b0de8870df998637fd0f by Mark Dickinson in branch 'main': bpo-43475: Add what's new entry for NaN hash changes (GH-26725) https://github.com/python/cpython/commit/1d10bf0bb9409a406c56b0de8870df998637fd0f

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Mark Dickinson : -- pull_requests: +25315 pull_request: https://github.com/python/cpython/pull/26725 ___ Python tracker ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: > Does this change need to be mentioned in What's New? Yes, I think so, given that it's a change to documented behavior. It's also something that third party packages (like NumPy) potentially need to be aware of. --

[issue43475] Worst-case behaviour of hash collision with float NaN

python code always incurs a performance hit. Also, in your example, the subclass isn't technically correct because it relies on a non-guaranteed implementation details. It likely isn't even the fastest approach. The only guaranteed behaviors are that math.isnan(x) reliably detects a NaN an

[issue43475] Worst-case behaviour of hash collision with float NaN

realead added the comment: @mark.dickinson > ...my expectation was that there would be few cases of breakage, and that for > those few cases it shouldn't be difficult to fix the breakage. This expectation is probably correct. My issue is somewhat only partly on-topic here: If one wants to

[issue43475] Worst-case behaviour of hash collision with float NaN

Serhiy Storchaka added the comment: Does this change need to be mentioned in What's New? -- ___ Python tracker ___ ___

[issue43475] Worst-case behaviour of hash collision with float NaN

miss-islington added the comment: New changeset 128899d8b8d65d86bd9bbea6801e9f36e6f409f2 by Miss Islington (bot) in branch '3.10': bpo-43475: Fix the Python implementation of hash of Decimal NaN (GH-26679) https://github.com/python/cpython/commit/128899d8b8d65d86bd9bbea6801e9f36e6f409f2

[issue43475] Worst-case behaviour of hash collision with float NaN

Serhiy Storchaka added the comment: > Maybe a new comparator is called for (like PY_EQ_FOR_HASH_COLLECTION), which > would yield float("nan") equivalent to float("nan") and which should be used > in hash-set/dict? It is difficult to do from technical p

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +25292 pull_request: https://github.com/python/cpython/pull/26706 ___ Python tracker

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: @Serhiy: can this be closed again? Does GH-26679 need to be backported to the 3.10 branch? -- ___ Python tracker ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: @realead > This change makes life harder for people trying to get sane behavior with > sets [...] Yes, code that assumes that all NaNs have the same hash value will need to change. But that doesn't seem unreasonable for objects that are already considered

[issue43475] Worst-case behaviour of hash collision with float NaN

Serhiy Storchaka added the comment: New changeset 9f1c5f6e8af6ba3f659b2aea1e221ac9695828ba by Serhiy Storchaka in branch 'main': bpo-43475: Fix the Python implementation of hash of Decimal NaN (GH-26679) https://github.com/python/cpython/commit/9f1c5f6e8af6ba3f659b2aea1e221ac9695828ba

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Serhiy Storchaka : -- pull_requests: +25265 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26679 ___ Python tracker ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Serhiy Storchaka added the comment: There is an error in the Python implementation of Decimal.__hash__. It calls super().__hash__(), but the C implementation calls object.__hash__(). Also, the documentation for floating point hash has the same error. -- stage: resolved -> status:

[issue43475] Worst-case behaviour of hash collision with float NaN

realead added the comment: This change makes life harder for people trying to get sane behavior with sets for float-, complex- and tuple-objects containing NaNs. With "sane" meaning, that set([nan, nan, nan]) => {nan} Until now, one has only to override the equ

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: Opened https://github.com/numpy/numpy/issues/18833 -- ___ Python tracker ___ ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: Thanks, Raymond. I'll open something on the NumPy bug tracker, too, since they may want to consider doing something similar for numpy.float64 and friends. -- ___ Python tracker

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43475] Worst-case behaviour of hash collision with float NaN

Raymond Hettinger added the comment: New changeset a07da09ad5bd7d234ccd084a3a0933c290d1b592 by Raymond Hettinger in branch 'master': bpo-43475: Fix worst case collision behavior for NaN instances (GH-25493) https://github.com/python/cpython/commit/a07da09ad5bd7d234ccd084a3a0933c290d1b592

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +24216 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25493 ___ Python tracker

[issue43475] Worst-case behaviour of hash collision with float NaN

Raymond Hettinger added the comment: > I'm loathe to guarantee anything about this in the language itself. There aren't language any guarantees being proposed. Letting the hash depend on the object id just helps avoid quadratic behavior. Making float('NaN') a singleton is also perfec

[issue43475] Worst-case behaviour of hash collision with float NaN

Tim Peters added the comment: I agree hashing a NaN acting like the generic object hash (return rotated address) is a fine workaround, although I'm not convinced it addresses a real-world problem ;-) But why not? It might. But that's for CPython. I'm loathe to guarantee anything about

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: > Why not have hash() return the id() like we do for instances of object? I think that's fine, and IIUC that's what Cong Ma was proposing. It seems like the least invasive potential fix. In principle I find the idea of making NaN a singleton rat

[issue43475] Worst-case behaviour of hash collision with float NaN

Raymond Hettinger added the comment: Mark, is there any reason hash(float('NaN')) and hash(Decimal('NaN')) have to be a constant? Since NaNs don't compare equal, the hash homomorphism has no restrictions. Why not have hash() return the id() like we do for instances of object? I

[issue43475] Worst-case behaviour of hash collision with float NaN

Raymond Hettinger added the comment: > And making float('nan') returning a singleton, > but 1e1000 * 0 returning different NaN would cause large confusion. Not really, it would be just be an implementation detail, no different than int and strings being sometimes unique and som

[issue43475] Worst-case behaviour of hash collision with float NaN

Serhiy Storchaka added the comment: What about Decimal NaN? Even if make float NaN a singleton, there will be other NaNs. And making float('nan') returning a singleton, but 1e1000 * 0 returning different NaN would cause large confusion. -- nosy: +serhiy.storchaka

[issue43475] Worst-case behaviour of hash collision with float NaN

Raymond Hettinger added the comment: > The performance thoughts were motivated by the idea of > making NaN a singleton: adding a check to > PyFloat_FromDouble would mean that almost every operation > that produced a float would have to pass through that check. It may suf

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: @Cong Ma: Yes, I'm not worried about performance for the change you're proposing (though as you say, we should benchmark anyway). The performance thoughts were motivated by the idea of making NaN a singleton: adding a check to PyFloat_FromDouble would mean

[issue43475] Worst-case behaviour of hash collision with float NaN

Cong Ma added the comment: > Idea: We could make this problem go away by making NaN a singleton. Apart from the fact that NaN is not a specific value/object (as pointed out in the previous message by @mark.dickinson), currently each builtin singleton (None, True, False, etc.) in Pyt

[issue43475] Worst-case behaviour of hash collision with float NaN

6.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import struct >>> snan_bits = 0x7ff000123456 >>> snan = struct.unpack(">> snan nan Converting back shows that the attempt was successful:

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: > We could make this problem go away by making NaN a singleton. That could work, though we'd annoy anyone who cared about preserving NaN payloads and signs in Python. I don't know if such people exist. Currently the sign is accessible through things l

[issue43475] Worst-case behaviour of hash collision with float NaN

Raymond Hettinger added the comment: Idea: We could make this problem go away by making NaN a singleton. -- ___ Python tracker <https://bugs.python.org/issue43

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: > I also wonder if there's security implication for servers that process > user-submitted input Yes, the "malicious actor" scenario is another one to consider. But unlike the string hashing attack, I'm not seeing a realistic way for the nan

[issue43475] Worst-case behaviour of hash collision with float NaN

Cong Ma added the comment: Sorry, please ignore my rambling about "float() returning aliased object" -- in that case the problem with hashing doesn't arise. -- ___ Python tracker

[issue43475] Worst-case behaviour of hash collision with float NaN

/issues/28363 yes apparently people do run into the "NaN as key" problem every now and then, I guess. (I'm not familiar enough with the poster's real problem in the Pandas setting to comment about that one, but it seems to suggest people do run into "real world" problems that

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: On third thoughts, of course it *would* help, because the Counter is keeping references to the realised NaN values. I think I'll go away now and come back when my brain is working. -- ___ Python tracker <ht

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: Hmm. On second thoughts, the proposed solution wouldn't actually *help* with the situation I gave: the elements (lazily) realised from the NumPy array are highly likely to all end up with the same address in RAM. :-( >>> x = np.full(10, np.nan) >>> for v in

[issue43475] Worst-case behaviour of hash collision with float NaN

Mark Dickinson added the comment: Sigh. When I'm undisputed ruler of the multiverse, I'm going to make "NaN == NaN" return True, IEEE 754 be damned. NaN != NaN is fine(ish) at the level of numerics; the problems start when the consequences of that choice leak into the o

[issue43475] Worst-case behaviour of hash collision with float NaN

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43475] Worst-case behaviour of hash collision with float NaN

New submission from Cong Ma : Summary: CPython hash all NaN values to 0. This guarantees worst-case behaviour for dict if numerous existing keys are NaN. I think by hashing NaN using the generic object (or "pointer") hash instead, the worst-case situation can be alleviated withou

  1   2   3   4   5   6   7   8   9   10   >