Re: Why not Ada? followup

[ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)]

In article <Jk6c1B2w165w@netlink.cts.com>,
mshapiro@netlink.cts.com (Michael Shapiro) excerpted
something that had been sent to him:
> ========================================================================
> I have used Ada for some projects, and we use Ada for most of
> our applications, but I must say I don't trust Ada. A numerical
> algorithm written in C and Ada often result in a different result
> in the two languages. C doesn't have to convert, convert,
> convert.... each time you do a calculation, Ada does and
> sometimes this results in a round-off error in intermediate
> results, giving erroneous final results.
> Try taking an integer, convert it to a FLOAT, do a lot of trig.
> functions and get a result. Then reverse the calculations and
> see if you get the original integer back..., in C you do.
> ========================================================================

The following rave against Ada was that there was no free Ada compiler.
Typical of the raves against Ada, that one relied on demonstrably false
hearsay.  (There _is_ a finished Ada compiler from NYU that is free.
I use it.  It's described in the comp.lang.ada FAQ posting.)

But this one about numbers has me completely bewildered.
Ada _has_ a floating-point model which an implementation _must_ adhere to.
C does not.  I have, and frequently study, the ISO C standard.  There are
NO useful guarantees about floating-point arithmetic in that standard.
There _are_ some useful guarantees about floating-point NUMBERS in the 
description of <limits.h>.  My point is that ok, you are guaranteed that
(double) has at least 10 decimal digits worth of precision, but you are
NOT guaranteed that addition preserves even one of those digits.
Again, what's all this b***s**t about convert, convert, convert?  If I
have
	x, y, z: some_floating_point_type;
	x := y+z;
in Ada there is no conversion required.  On the other hand, if I have
	float x, y, z;
	x = y+z;
in C, the standard _does_ mandate 3 conversions; it's equivalent to
	x = (float)((double)y + (double)z);
and a compiler writer is only allowed to do the addition in single
precision if s/he can prove that it makes no difference to the final
result.
And the third claim is quite literally incredible.  One reason that I
don't believe it is that I _have_ tried that kind of computation in C
and no it _doesn't_ work.  In general, of course, it couldn't possibly
work.  Proof:
	x = asin(sin(1.0 * N));
Anyone with even the most meagre grasp of numerical analysis will understand
why
	x = tan(atan(1.0 * N));
cannot be expected to work for all integers,   In fact, I tried it just
know using GCC 2.2.1 on an Encore Multimax, which has IEEE-754ish arithmetic,
and found
    n = 1, atan(n) = 0.785398, tan(atan(n))-n = -1.11022e-16
"Reverse the calculations and see if you get the original integer back."
In C you *don't*.  (And can't.  double != real.)

So this criticism of Ada boils down to "someone who relies on hearsay and
hasn't bothered to test his assumptions about C either and doesn't understand
computer arithmetic thinks that Ada has worse arithmetic than C."  Many of
the other raves were equally ill informed.

There _is_ a valid criticism which could be brought against Ada.
The Fortran standards (F66, F77, F90), the Algol standards (A60.1, A68),
the Pascal standards, and C all of them include trig functions.  The
Ada83 standard doesn't.  (Which means, in practice, that many Ada systems
offer bindings to the same library that C uses, which makes the rave above
even sillier.)  A lot of work has gone into defining trig (and other)
functions for Ada, and I would _love_ to have something that met the draft
spec I saw a while back.