Add std::hash<podio::ObjectID> specialization

[veprbl]

BEGINRELEASENOTES

• Added std::hash<podio::ObjectID> specialization to allow std::unordered_map<podio::ObjectID, T>

ENDRELEASENOTES

This helps with writing algorithms based around PODIO types. Perhaps we could next provide hash definitions for PODIO objects themselves.

[tmadlener]

I am wondering whether this has the necessary properties that should be met for usage in a hash map, e.g. does it distribute the hashes wide enough and how likely are collisions?

I suppose a theoretical estimate of those is kind of hard to come by, but I am wondering whether we should put in some checks to avoid at least some of the potentially subtle issues.

For example, since the set of distinct collectionIDs that we get is fairly finite and I think we went through the exercise in #412 of collecting a reasonable superset of the ones we have encountered so far. We could use a reasonable range of index values to at least test for collisions in that range, and maybe even check load factors for unordered_map. However, I am not entirely sure whether the range that we could cover can serve as a reasonable test here.

[tmadlener]

Technically the collectionID is (almost certainly) already a 32 bit hash.

[veprbl]

I'm not sure how that helps here. I assume, hash is still better to cover domain of size_t.

[veprbl]

I am wondering whether this has the necessary properties that should be met for usage in a hash map, e.g. does it distribute the hashes wide enough and how likely are collisions?

In our typical applications (different elements of the same collection), it shouldn't be any different from defining std::unordered_map<int, T>.

[tmadlener]

Follow up question after the EDM4hep meeting today. Would it be of general interest to also have the generated user facing objects, e.g. MCParticle, have a specialized std::hash? We currently have operator< to make std::map or std::set usable but it should be possible to make a std::hash spezialization available as well if that is something that is considered as generally useful.

[veprbl]

Yes, that's desirable.

[tmadlener]

Merging this now. Support for hashing handles coming with #738

[m-fila]

I think XOR is fine for our usage. Just for completeness, a more sound approach would be something like boost::hash_combine ( and about design) but implementing this just for this usage is an overkill

[tmadlener]

Yeah that was my original concern, because I knew about all the things in boost, but didn't want to pull in a boost dependency just for this. In any case, I think we can merge this as is, as #738 will probably be the more used thing and if we realize issues with this we can change the implementation for ObjectID pretty easily without affecting interfaces or anything that is persisted.

[veprbl]

Yes, that was considered, and, perhaps, I should have left a comment.
The collectionID is expected to be either a negative non-unique constant or a very high semi-unique number (already a hash), which makes it up to hash of index (small number values) to provide uniqueness. For that reason a simple xor without shifts was employed.