-
Notifications
You must be signed in to change notification settings - Fork 126
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
Add hash
methods for many types with ==
method
#2373
Conversation
fa49b72
to
0f39d99
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2373 +/- ##
==========================================
- Coverage 72.94% 72.82% -0.13%
==========================================
Files 405 405
Lines 53781 53874 +93
==========================================
+ Hits 39232 39235 +3
- Misses 14549 14639 +90
|
hash
methods for types with ==
methodhash
methods for many types with ==
method
Most implementations are purely based on the things that are compared in the |
441a5a9
to
91bcf5d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hash functions apprea to be correct, but are very weak in many cases. Can someone from teh geometry crowed maybe have a look?
Fundamentally, I'm not sure if a weak hash function is better than throwing an error. Several hash functinos introduced here shuold never be used.
src/AlgebraicGeometry/ToricVarieties/AlgebraicCycles/constructors.jl
Outdated
Show resolved
Hide resolved
4bc4e96
to
2fc7c8e
Compare
src/Rings/mpoly-localizations.jl
Outdated
function Base.hash(T::AbsMPolyMultSet, h::UInt) | ||
b = 0x7ce51a28c47ec5e1 % UInt | ||
h = hash(typeof(T), h) | ||
h = hash(ambient_ring(T), h) | ||
return xor(h, b) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the effort! However, this kind of hashing will not be sufficient. Instead, I propose to throw an error here which requires the user to overwrite the hash function for their concrete type.
Can I do that and push to this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean something similar to this?
Oscar.jl/src/Rings/mpoly-localizations.jl
Line 529 in 96c2eed
error("comparison of multiplicative sets of type $(typeof(T)) and $(typeof(U)) is not implemented") |
Yeah, that would be great. Please text me on slack to coordinate, so that we delete nothing by accidentally force pushing anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a warning in 0dfcbe8. Is this fine with you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After looking a bit deeper into the concrete subtypes, I think there cannot be special implementations of hash
for each type. There are many different implementations for issubset
for different pairs of types, and equality is just defined generically using issubset
. Since AbsMPolyMultSets of different concrete types can be equal, their hashes should coincide as well. And I do not see how to do that with specialized implementations.
In principle this is fine by me, but there is (a) a conflict and (b) this is marked as a draft, so I won't look closer for now. |
Let's see if the CI runs without any warnings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
function Base.hash(a::SubquoModuleElem, h::UInt)
the current hash does not depend on the element, only on the parent. This is julia-correct, but is this what you want? I'd rather throw an error... @HechtiDerLachs ?
Similar: GAPGroupHomomorphism @fingolfin is there a decent hash for f.map or should this be an error?
I don't see a way to define an efficient hash for group morphisms, so I think that should throw an error |
I would refrain from throwing errors in these cases to not render these types useless for anyone who needs to use them in some container/setting with hashing (even without knowning). Instead, I would like to have some kind of warning. If possible, this warning should be marking the CI as failed. |
If the warning is supposed to make CI fail, why not error in the first place? Or why not define the hash to be |
The latter is my proposal in this PR. I use every little bit of information to make at least some hashes different to at least circumvent hash conflicts for objects of completely different types. |
That's one way to put it, as an advantage. But there's also the counterpoint: with a 0-hash, one can use these objects as keys for a container, without noticing at first that this is a terrible idea with worst case performance. Other than for toy examples it won't be useful... That's why I'd rather have an error in those cases... |
src/Modules/UngradedModules.jl
Outdated
b = 0x0361a2f6467e4200 % UInt | ||
h = hash(parent(a), h) | ||
return xor(h, b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is (one of?) the contentious parts: we (@fieker and me) don't think this is really better (in practical applications) than a function returning a constant, and that of course is mostly useless. So we'd favor an error indicating "not implemented".
Actually, to make it stronger: we require this to merge the PR. However, of course if we run into actual problems caused by this, we can revisit the situation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed in 722eccf.
I still think this is a bad idea and could potentially render Oscar useless for some users that rely on some julia Base functionality that uses hashing. I would prefer to return 0 or some constant and give a warning (that in the best case should make CI fail) instead. Then, some user can still use Oscar types for their use-case, although it may be very inefficient in those cases.
But if this is what you want, let's go with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge this if tests pass now
This addresses parts of #2222 and resolves #1264.
Julia requires that equal elements (w.r.t.
==
) hash to the same value to makeSet
s etc. work.For many OSCAR types (cf. #2222), there currently is a dedicated
==
, but nohash
; thus contradicting the requirement.