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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk