From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-116863-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17234 invoked by alias); 6 Jul 2005 13:50:35 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 17212 invoked by uid 22791); 6 Jul 2005 13:50:28 -0000
Received: from smtp-103-wednesday.noc.nerim.net (HELO mallaury.nerim.net) (62.4.17.103)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 06 Jul 2005 13:50:28 +0000
Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186])
	by mallaury.nerim.net (Postfix) with ESMTP id 9D3284F3A4;
	Wed,  6 Jul 2005 15:50:17 +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 j66DoJpI002315;
	Wed, 6 Jul 2005 15:50:20 +0200
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j66DoJHa002314;
	Wed, 6 Jul 2005 15:50:19 +0200
To: Avi Kivity <avi@argo.co.il>
Cc: Michael Veksler <VEKSLER@il.ibm.com>, gcc@gcc.gnu.org
Subject: Re: tr1::unordered_set<double> bizarre rounding behavior (x86)
References: <OFD333D6F7.1728E61D-ON43257036.00466F4A-43257036.0046EB9E@il.ibm.com>
	<1120654859.2989.4.camel@blast.q>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <1120654859.2989.4.camel@blast.q>
Date: Wed, 06 Jul 2005 13:50:00 -0000
Message-ID: <m3mzp0yrfo.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2005-07/txt/msg00227.txt.bz2

Avi Kivity <avi@argo.co.il> writes:

| On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
| 
| > > most architectures have different bit representations for +0.0 and -0.0,
| > > yet the two values compare equal.
| > >
| > 
| > Yet, their sign bit is observable through   things like
| >   assert(a == 0.0);
| >   assert(b == 0.0);
| >   1/(1/a+ 1/b)
| > which would give either NaN or 0 depending on the sign
| > of a and b.
| > 
| > So do you want one or two copies in the set?
| > 
| what matters is whether the sign bit is observable through the equality
| predicate. in the case of the operator==(double, double), it is not
| observable, so there should be only one copy in a set.

Yes.

That logical framework has some "problems" though.  Assume x is  NaN,
then you would end up with as many xs as you insert in the set.

-- Gaby