From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15653 invoked by alias); 5 Jul 2005 17:04:33 -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 15638 invoked by uid 22791); 5 Jul 2005 17:04:30 -0000 Received: from ns.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 05 Jul 2005 17:04:30 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 9B986DD61; Tue, 5 Jul 2005 19:04:27 +0200 (CEST) Message-ID: <42CABDCC.3070508@suse.de> Date: Tue, 05 Jul 2005 17:04:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 MIME-Version: 1.0 To: Michael Veksler Cc: gcc@gcc.gnu.org Subject: Re: tr1::unordered_set bizarre rounding behavior (x86) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00171.txt.bz2 Michael Veksler wrote: > std::tr1::hash is implemented in a very bad way. > it casts double to size_t, which of course does a very poor job on big > values (is the result of 1.0e100 cast to size_t defined ?). > > A possible solution would be using frexp & co to extract the mantissa and then work on it, one way or the other. You can find it proposed around. Then, often the exponent is simply discarded. What do you think? In case, please add your comments to the audit trail of 21193. I mean to work pretty soon on improving those hash functions. Paolo.