Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overload for hash(::Sym, ::UInt64) missing #520

Closed
jlbosse opened this issue Sep 19, 2023 · 1 comment · Fixed by #522
Closed

Overload for hash(::Sym, ::UInt64) missing #520

jlbosse opened this issue Sep 19, 2023 · 1 comment · Fixed by #522

Comments

@jlbosse
Copy link

jlbosse commented Sep 19, 2023

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))
# true

hash((sin(t),)) == hash((s,))
# false

# because 
hash(sin(t), zero(UInt64)) == hash(s, zero(UInt64))
# false

# even though
(sin(t),) == (s,)
# true

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 implies hash(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.

@jverzani
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants