Subject: Re: [boost] [hash] regular behaviour of hash function for double values
From: Daniel James (dnljms_at_[hidden])
Date: 2012-02-02 17:26:19
On 1 February 2012 21:13, Topher Cooper <topher_at_[hidden]> wrote:
> On 2/1/2012 3:59 AM, Daniel James wrote:
>>
>> 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.
Funnily enough, that wasn't actually my design decision. Well, I
suppose I chose to follow someone else's design. Given the
requirements (meeting the draft standard, being highly portable
without requiring too much development effort), I do think it was the
right decision. And you've provided no evidence to the contrary, which
is
> 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.
I do feel an obligation to respond to emails concerning my libraries.
I know I shouldn't but there you go.
> 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.
I mentioned the implementation of std::hash<int> in both libc++ and
libstdc++ earlier.
> 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.
Blimey. If it wasn't clear, I'm very happy for other people to propose
a new hash library. This one was written to meet a need, not to be the
bestest hash function ever. The only real problem has been the
implicit cast issue.
> 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.
I'm sorry I forced you to waste your time.
> 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.
You seem to be arguing against a point of view that no one holds by
using my explanation for not holding that point of view.