Re: tr1::unordered_set<double> bizarre rounding behavior (x86)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Paolo Carlini <pcarlini@suse.de> writes:

| Gabriel Dos Reis wrote:
| 
| >Joe Buck <Joe.Buck@synopsys.COM> writes:
| >
| >| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| >| > It is definitely a good thing to use the full bits of value
| >| > representation if we ever want to make all "interesting" bits part of
| >| > the hash value.  For reasonable or sane representations it suffices to
| >| > get your hand on the object representation, e.g.:
| >| > 
| >| >    const int objsize = sizeof (double);
| >| >    typedef unsigned char objrep_t[objsize];
| >| >    double x = ....;
| >| >    objrep_t& p = reintepret_cast<objrep_t&>(x);
| >| >    // ...
| >| > 
| >| > and let frexp and friends only for less obvious value representation.
| >| 
| >| I disagree; on an ILP32 machine, we pull out only 32 bits for the hash
| >| value, and if you aren't careful, your approach will wind up using the
| >| least significant bits of the mantissa.  This will cause all values that
| >| are exactly representable as floats to collide.
| >
| >I'm not sure we're talking about the same thing.  With the
| >representations I'm talking about, value repsentation == object representation.
| >
| ... still, the hash functions for float, double and long double that we
| need for TR1 must return a size_t (6.3.3). How do you get a size_t from
| an objrep_t?

The same way you would get a hash value out of

  unsigned char [N * sizeof(size_t)]

?

| (fulfilling the various requirements briefly reminded by
| Joe in his first message)

I don't think Joe understood I was talking about hashing the value
representation of the floating point object.

If you regard the object representation as an array of bytes, does it
take long realize it is not much different from hashing a character
string? 

-- Gaby