jcea has quit [Quit: jcea]
jcea1 has joined #pypy
jcea1 is now known as jcea
jcea1 has joined #pypy
jcea has quit [Ping timeout: 248 seconds]
jcea1 is now known as jcea
lehmrob has joined #pypy
jcea has quit [Ping timeout: 248 seconds]
lehmrob has quit [Ping timeout: 248 seconds]
Julian has joined #pypy
Atque has joined #pypy
Julian has quit [Quit: leaving]
lehmrob has joined #pypy
otisolsen70 has joined #pypy
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #pypy
sugarbeet has quit [Ping timeout: 256 seconds]
sugarbeet has joined #pypy
otisolsen70 has quit [Quit: Leaving]
Dejan has joined #pypy
lehmrob has quit [Ping timeout: 246 seconds]
lehmrob has joined #pypy
jcea has joined #pypy
sugarbeet has quit [Ping timeout: 248 seconds]
sugarbeet has joined #pypy
otisolsen70 has joined #pypy
epony has quit [Read error: Connection reset by peer]
Atque has quit [Ping timeout: 255 seconds]
Atque has joined #pypy
epony has joined #pypy
lehmrob has quit [Ping timeout: 248 seconds]
lehmrob has joined #pypy
lehmrob has quit [Ping timeout: 248 seconds]
otisolsen70 has quit [Remote host closed the connection]
otisolsen70_ has joined #pypy
<
mattip>
py3.10 changes hash(nan) to return the hash of the object pointer, not 0
<
mattip>
in order to do this, they changed the signature of a cpyext (admittedly "private") function _Py_HashDouble
otisolsen70_ has quit [Quit: Leaving]
<
mattip>
that's nice for cpython, but what do we do to hash a float-strategy list with nans: we don't have a object wrapping the float value
<
mattip>
we want the result to be consistent (the list hash should always return the same value), so the algorithm cannot be totally random
<
mattip>
but if a new nan is put in place of the current one, the hash should change
<
mattip>
maybe NumPy already solved this problem, let's see what they did
sol_ has joined #pypy
sol__ has quit [Ping timeout: 255 seconds]
<
cfbolz>
mattip: yes, I was wondering about this too :-(
<
cfbolz>
mattip: but I think we don't even
*have* the bug that they are trying to fix with this
<
cfbolz>
what they are fixing is having a dict with nan as keys
<
cfbolz>
and that devolves into a linear lookup or something?
<
cfbolz>
but in our case we do the right thing
<
mattip>
numpy didn't do anything special to create unique nans
<
mattip>
cfbolz: what kind of right thing?
glyph has quit [Quit: End of line.]
<
cfbolz>
mattip: and in pypy it is
*already* not quadratic
<
cfbolz>
because float('nan') is float('nan')
glyph has joined #pypy
<
cfbolz>
so imo we just document this change
<
mattip>
so for this snippet "a={}; for i in range(10): a[float('nan')] = 1"
<
mattip>
on PyPy len(a) is 1, on CPython it is 10
<
cfbolz>
that is fine imo
<
cfbolz>
the point is that if you increase the 10, the complexity becomes quadratic in cpython3.9
<
cfbolz>
but not in cpython3.10
<
cfbolz>
and not in pypy
<
mattip>
the result is very different as well, but I guess no-one has complained so far
<
mattip>
I wonder if they even considered that solution to the issue
<
cfbolz>
it's much more annoying in their case I think
<
cfbolz>
they would have to check for nan at every single place they construct floats
<
mattip>
ok, I will add the new interface for cpyext and add a blurb to cpython-differences, and leave the pypy code alone
<
cfbolz>
that sounds good to me
* mattip
fixing other links too
<
cfbolz>
coming along nicely, the positions are working :-)
<
cfbolz>
mattip: the test_exceptions failures also went down a bit
<
cfbolz>
but still a bunch of details
<
mattip>
the latest commits fix building for numpy
lehmrob has joined #pypy
lehmrob has quit [Ping timeout: 246 seconds]
lehmrob has joined #pypy
lehmrob has quit [Ping timeout: 246 seconds]
<
nimaje>
(but why would you use NaN as a key in a hashmap? especially when your language does not gurantee float('nan') is float('nan')?)