You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the implementation of hash(x::Sym, h::UInt64) depends on the object id and not value of x, whereas hash(x::Sym) depends on the value of x. This leads to counter intuitive behaviour like the following:
using SymPy
t =symbols("t")
s =sin(t)
hash(s) ==hash(sin(t))
# truehash((sin(t),)) ==hash((s,))
# false# because hash(sin(t), zero(UInt64)) ==hash(s, zero(UInt64))
# false# even though
(sin(t),) == (s,)
# true
Thanks for this. Following your discourse discussion, I put in a PR to PyCall (JuliaPy/PyCall.jl#1054) which along with the definition hash(x::Sym, h::UInt64) = hash(PyObject(x), h) should get this done. Let me see if that is accepted and if not, look to solve this within SymPy.
Currently the implementation of
hash(x::Sym, h::UInt64)
depends on the object id and not value ofx
, whereashash(x::Sym)
depends on the value of x. This leads to counter intuitive behaviour like the following:See also this issue for consequences of the missing hash function and this discussion on discourse for why this is an issue.
I think, and the julia documentation also clearly states, that the hash function should satisfy
x == y
implieshash(x) == hash(y)
.I am happy to create a PR that implements the two-argument version
hash(x::Sym, h::UInt64)
which should fix this; If that is the desired behaviour.The text was updated successfully, but these errors were encountered: