From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3675 invoked by alias); 5 Jul 2005 19:01:18 -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 3652 invoked by uid 22791); 5 Jul 2005 19:01:04 -0000 Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 19:01:04 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j65J12ew223984 for ; Tue, 5 Jul 2005 19:01:02 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j65J12vc161428 for ; Tue, 5 Jul 2005 21:01:02 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j65J12wQ018618 for ; Tue, 5 Jul 2005 21:01:02 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j65J12vK018613 for ; Tue, 5 Jul 2005 21:01:02 +0200 In-Reply-To: <20050705181025.GB2315@synopsys.com> Subject: Re: tr1::unordered_set bizarre rounding behavior (x86) To: Joe Buck Cc: gcc@gcc.gnu.org, Gabriel Dos Reis Message-ID: From: Michael Veksler Date: Tue, 05 Jul 2005 19:01:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2005-07/txt/msg00185.txt.bz2 Joe Buck wrote on 05/07/2005 21:10:25: > 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. For that you can do something like (or templated equivalent): namespace Impl { template size_t floating_point_hash(T in) { if (sizeof(in) <= sizeof(size_t)) Use Gaby's solution, with zero padding; else frexp and friends using Joe Buck's ideas; } } Gaby's solution should be done with care - to avoid any aliasing issues (never go directly from double& to size_t&). Both Gaby's and Joe Buck's solutions do not take the strangeness of IEEE (NNN?) into account. As I remember it (I don't have the reference at home), IEEE FP has many bit-representations for NaN, each containing some bit-encoding of errors. It has been years since I last saw the standard of IEEE FP, so I may give wrong details, but the main idea should be correct. "There *should* be a specialization for equal_to that provides a strict weak ordering for NaNs as well as other values." [quoted forwarded mail from P.J. Plauger] Doing bit-wise conversions will not address this requirement. Michael