Re: [boost] [hash] regular behaviour of hash function for double values

Subject: Re: [boost] [hash] regular behaviour of hash function for double values
From: Topher Cooper (topher_at_[hidden])
Date: 2012-02-01 16:13:01

On 2/1/2012 3:59 AM, Daniel James wrote:
> Why do you think I said I didn't want to get into this debate?
I'm sympathetic -- I don't have time for this either, but I didn't feel 
that leaving these points of your justification unanswered was responsible.
>   I do
> realise that there's a lot to say, and I don't have any enthusiasm for
> saying it. I wrote the thing 7 years ago.
>    
I've made lots of much worse errors in the past -- nothing wrong about 
that.  And you are to be commended, like all the Boost library 
implementors, for having made a substantial contribution.  If you don't 
want to defend the decisions you made, though, just admit to 
misjudgement or let it pass.
> IMO a more appropriate forum would be one of the C++ newsgroups, as
> this is more about how the standard should be implemented, rather than
> my particular implementation which should really become obsolete over
> the coming years. Boost.Hash's advantages over standard
> implementations are its portability and its customisation abilities.
>    
The quality of the Boost implementation and whether it conforms to the 
requirements and Boost quality standards belongs in the Boost list.  
There may also be a place for part of the discussion in more general C++ 
lists, if the belief that the specs imply low quality hash functions is 
widespread in the community.  Could be, but I have no evidence to that 
effect.

The point is that there is a case to be made that this implementation 
should have been obsolete seven years ago at its birth.  That this 
wasn't caught by the community back then is a failure of the whole 
community -- especially those of us who know something about the 
subject, even those like me whose community participation is sporadic.  
We can't do anything about the last seven years, but I think that it is 
clear that it should already be considered obsolete, and that replacing 
it should be a group priority.  Unfortunately, my clients would be 
justified, I'm afraid, in considering the time I've spent writing on 
this as being somewhat irresponsible to them (deadlines long since unmet 
on work already paid for).  If someone hasn't done something when I come 
up for air, I'll see about fixing this myself.

As for its customisation (cap)abilities you argued earlier in the same 
message that a major aspect of its customizability is that it can be 
replaced with something else.