Re: future of the C++
nmm1@cam.ac.uk wrote:
In article <i0u2r7$tpa$1@news.eternal-september.org>,
Walter Bright <walter@digitalmars-nospamm.com> wrote:
I am afraid not. That is true for only some architectures and
implementations, and is one of the great fallacies of the whole
IEEE 754 approach. Even if a 'perfect' IEEE 754 implementation
were predictable, which it is not required to be.
Can you elucidate where the IEEE 754 spec allows unpredictability?
Mainly in the handling of the signs and values of NaNs: "this
standard does not interpret the sign of a NaN". That wouldn't
matter too much, except that C99 (and hence C++0X and IEEE 754R)
then proceeded to interpret them - despite not changing that!
You're right, I'd forgotten about the NaN "payload" bits. But I also
think that
is irrelevant to getting accurate floating point results.
For the sign of NaN, you're right as well, but it's also irrelevant. The
only
reason C99 mentions this is because it's efficient for testing/copying
the sign
bit without also having to test for NaN'ness. Any code that depends on
the sign
of NaN is broken.
Also, in IEEE 754R, the rounding mode for decimal formats.
Does anyone use the decimal formats?
I understand that the FP may use higher precision than specified by the
programmer, but what I was seeing was *lower* precision. For example,
an 80 bit transcendental function is broken if it only returns 64 bits
of precision.
Not at all. I am extremely surprised that you think that. It would
be fiendishly impossible to do for some of the nastier functions
(think erf, inverf, hypergemetric and worse) and no compiler I have
used for an Algol/Fortran/C/Matlab-like language has ever delivered it.
I agree that if it's impractical to do it, then requiring it is, ahem,
impractical. But I see these accuracy problems in functions like tanh() and
acosh(), where some C libraries get them fully accurate and others are
way off
the mark. Obviously, it is practical to get those right.
Other lowered precision sloppiness I've seen came from not implementing
the guard and sticky bits correctly.
Well, yes. But those aren't enough to implement IEEE 754, anyway.
Aren't enough, sure, but necessary, yes.
Other problems are failure to deal properly with nan, infinity, and
overflow arguments.
I don't believe such carelessness is allowed by IEEE 754, and even
if it was, it's still unacceptable in a professional implementation.
Even now, IEEE 754 requires only the basic arithmetic operations,
and recommends only some of the simpler transcendental functions.
Have you ever tried to implement 'perfect' functions for the less
simple functions? Everyone that has, has retired hurt - it's not
practically feasible.
I was following the NCEG (Numerical C Extensions Group) back around 1991
or so,
and they came out with a document describing what each standard C library
function should do with NaN and infinity. I implemented all of that in
my C/C++
compiler. None of it was rocket science or impractical. It's a darned
shame that
it took 15+ years for other compilers to get around to doing it.
Things have changed. Longer ago than that, a few computers had
unpredictable hardware (the CDC 6600 divide was reported to, for
example, but I didn't use it myself). But the big differences
since 1980 and now are:
1) Attached processors (including GPUs) and alternate arithmetic
units (e.g. vector units, SSE, Aptivec etc.) These usually are
not perfectly compatible with the original arithmetic units,
usually for very good reasons.
2) The widespread use of dynamic optimisation, where the code or
hardware chooses a path at run-time, based on some heuristics to
optimise performance.
3) Parallelism - ah, parallelism! And therein hangs a tale ....
I have no problem with, for example, a "fast float" compiler switch that
explicitly compromises fp accuracy for speed. But such behavior should
not be
enshrined in the Standard.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]