Hi Florian, The idea is indeed to specialize std::hash<GiNaC::ex> around ex::gethash() which falls back to CLN's hashes for objects of numeric type. Is there anything wrong with this simple approach? Is it that size_t return value which is 64 bit on modern systems so that the 32 most significant bits remain unused? (How big do you expect your hash maps to get?) Have a look at ginac/hash_map.h remembering that std::unordered_map<> is basically a hash map! All my best, -richard. PS: CC'ing to the ginac-devel list. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/> On 11/27/25 9:23 AM, Florian Lorkowski wrote:
Dear Bruno,
thank you for the detailed explanation.
We were working on an algorithm that caches composite objects in GiNaC by their hash value. We will implement a system to handle hash collisions. In the long run this is safer anyway. Had we not caught this issue at this stage, we might have run into some really hard to investigate bugs later on.
Best regards Florian