From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21079 invoked by alias); 5 Jul 2005 19:18:22 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21064 invoked by uid 22791); 5 Jul 2005 19:18:18 -0000 Received: from smtp-102-tuesday.nerim.net (HELO kraid.nerim.net) (62.4.16.102) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 19:18:18 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by kraid.nerim.net (Postfix) with ESMTP id 0E80640E25; Tue, 5 Jul 2005 21:18:15 +0200 (CEST) Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j65JH7KY007525; Tue, 5 Jul 2005 21:17:07 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j65JH7Tq007524; Tue, 5 Jul 2005 21:17:07 +0200 To: Paolo Carlini Cc: Joe Buck , gcc@gcc.gnu.org Subject: Re: tr1::unordered_set bizarre rounding behavior (x86) References: <42CABDCC.3070508@suse.de> <20050705181025.GB2315@synopsys.com> <42CAD4AC.6040008@suse.de> From: Gabriel Dos Reis In-Reply-To: <42CAD4AC.6040008@suse.de> Date: Tue, 05 Jul 2005 19:18:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-07/txt/msg00188.txt.bz2 Paolo Carlini writes: | Gabriel Dos Reis wrote: | | >Joe Buck 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(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