This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tr1::unordered_set<double> bizarre rounding behavior (x86)
- From: Avi Kivity <avi at argo dot co dot il>
- To: Michael Veksler <VEKSLER at il dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Wed, 06 Jul 2005 16:00:59 +0300
- Subject: Re: tr1::unordered_set<double> bizarre rounding behavior (x86)
- References: <OFD333D6F7.1728E61D-ON43257036.00466F4A-43257036.0046EB9E@il.ibm.com>
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.