I'm terribly sorry, but everything which makes the hash function worse (slower or produces more collisions) is not acceptable. If you insist on that regardless of how it affects overall
Hi, On 29 May 2014 07:31, Alexei Sheplyakov <alexei.sheplyakov@gmail.com> wrote: performance, it is not a technical problem and cannot be fixed with a patch. In any case, if my previous patches are not acceptable for whatever reasons GiNaC developers might have, I suggest to close this discussion by adding a configure option. So users can decide for themselves if (non-)determinism is worth few per-cent speed difference. Below is the simplest patch one can imagine. By default it keeps things as they are now. If user specifies --enable-determinism then make_hash_seed simply returns 0. Objects with the same calchash() implementation *and* the same contents *but* different types will have a hash collision, which be resolved in base::compare by using typeid_1.before(typeid_2) (on Linux it is a simple strcmp). Since it happens quite rarely (depends on a particular code of course), it is better than always using crc32 as in windows version of your code. In fact it can sometimes be faster than current "fast" hash. Best, Valery