Re: std::sort causes segfault when sorting class arrays
On Mar 1, 10:56 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Thomas J. Gritzan wrote:
Sorry for being off-topic, but this is directly related to
the C++ problem of this thread.
Juha Nieminen wrote:
Victor Bazarov wrote:
I don't know what you're talking about, guys. I just took
your code, plugged it into my test project, compiled, ran,
and got 'true'. Changed FP settings, changed to
optimized, same thing. Maybe Visual C++ 2008 is wrong
somehow, and I am supposed to get 'false'?
No, the outcome is implementation defined. Arguably, your
implementation has the _better_ result.
The outcome is definitely not implementation defined. The
accuracy (and repeatability?) of expression evaluation is
unspecified.
The x86 floating point co-processor operates on 80 bit
floating point values. Temporaries stored in memory are in
64 bit double precision format. So by storing the first
result into a temporary, it was truncated and rounded to 64
bit, and by loading it back, it was extended to 80 bit
again. The second result still is 80 bit when the two are
compared.
Yup, and that's ok with the standard by [5/10].
Within an expression. As far as I know, the value with extended
precision *must* be rounded to double when it is used to
initialize a double, e.g. the return value.
In g+++, this is under control of the option -ffloat-store.
Regretfully, the default results in the non-conformant and
unexpected behavior, and the documentation of the option
suggests that it usually doesn't matter, where as it often does.
Sounds like BS to you, Juha? ;-)
That's why your teacher told you never to compare two
floating point values using equality.
Actually, _that_ is not the reason I heard. I thaught equality
is very likely not what you want anyway because of what the
floating point numbers in your program represent.
Actually, I've yet to hear anyone who really knows floating
point make such a recommendation. (It certainly doesn't apply
here, because there is no comparison for equality in the
original code.) What I have heard is that to use machine
floating point, you need to understand it first. And that it
can have some rather unexpected properties; the fact that you
can't actually know the precision of intermediate values---that
a double isn't necessarily a double---is perhaps the most
surprising ones (and is, of course, not inherent in floating
point, but rather a particularity of one particular
implementation).
However, it is true that the excess precision in registers can
screw up comparisons. But it can be prevented forcing a
write-reread cycle.
Not with g++, unless you specify -ffloat-store.
The program
#include <iostream>
#include <iomanip>
#include <cmath>
using namespace std;
bool equal ( double const & lhs, double const & rhs ) {
return ( lhs == rhs );
}
int main ( void ) {
double x = 1;
double y = 1;
cout
<< boolalpha
<< equal( sin(x)+cos(y), sin(x)+cos(y) ) << '\n';
}
prints true. I am not certain whether the standard requires
that or not, but since the OP also uses gcc on an intel
platform, the example pertains to the behavior he observes.
Note, however, that the above doesn't force a write-reread cycle
any more than the original, at least according to the standard.
(None of the writes or reads are "observable behavior".) It
would be interesting to look at the generated code under
optimization; I wouldn't be surprised if g++ drops both writes,
and that it works because neither value has been truncated to
double, not because both have been.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34