Hi Michael,
PJP agreed on my forwarding his answers to the issue you raised.
--- Begin Message ---
To: C++ libraries mailing list
Message c++std-lib-15219
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Gabriel Dos Reis
> Sent: Tuesday, 05 July, 2005 10:36
> To: undisclosed-recipients:
> Subject: tr1::unordered_set<double> bizarre rounding behavior (x86)
>
> The attached message just arrived in my mailbox. While it mentions
> a particular implementation, I believe it raises an important issue
> that arises in practice and warrants a clarification with respect to
> floating-point numbers.
>
> Currently, the standard does not mandate any particular floating
> point model nor anything very precise. However, that leads to
> practical issues; and I'm sure we should continue sticking our head in
> the sand :-)
>
> C99 has moved to a "more precise" model -- still without
> requiring it.
> I see various proposals to have "numerical" headers to C++; I think we
> should also revise our numeric models.
The floating-point model has little to do with the observed behavior,
which is arguably just a gcc bug. From the attachment:
: 1. Is it forbidden by tr1 to define unordered_set<double> ?
No.
: 2. Is it a bug in the tr1 document (which should have forbidden this).
No.
: 3. Is it OK to have repetitions in unordered_set?
No.
: 4. Is it a bug in gcc, for handling double the way it does?
Yes. If it can somehow conclude that two insertions (of apparently
exactly the same value) are unequal, but that they compare equal
when found in the set, that's a bug pure and simple. Whether the
bug lies in the compiler or the library remains to be determined.
: 5. Is it a bug in the implementation of tr1 in libstdc++ ?
Possibly. Or possibly the code is compiled improperly.
: Maybe handling of double should move to a different
: translation unit, to avoid aggressive inlining.
That may be necessary to dodge a gcc compiler bug.
: Or maybe
: there should be a specialization for equal_to<double>,
: where error bands will be used.
There *should* be a specialization for equal_to<double> that
provides a strict weak ordering for NaNs as well as other
values. There *should not* be "error bands" or any other
ad hoc kludge for deciding when two floating-point values
are "close enough."
: Using error bands will work fine for unordered_set<doble> insertion.
: It may lead to the "loss" of close entries, but in case of double it
sounds
: reasonable.
Not to me.
: P.S.
: std::tr1::hash<dobule> 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 ?).
Not really. There are certainly better ways to hash floating-point
values.
P.J. Plauger
--- End Message ---
--
Gabriel Dos Reis
[EMAIL PROTECTED]
