Re: Fortran or Ada?

[dewarr@my-dejanews.com]

In article <6vdnqe$3nu@bgtnsc02.worldnet.att.net>,
  "James Giles" <jamesgiles@worldnet.att.net> wrote:
>
> dewarr@my-dejanews.com wrote in message <6vdfq4$p1$1@nnrp1.dejanews.com>...
> >In article <YGdS1.73461$hx3.8968466@HME2.newscontent-01.sprint.ca>,
> >  "Ian St. John" <istjohn@sprint.ca> wrote:
> >>
> >> Testing by itself can never guarantee correct code. The testing is just to
> >> determine syntax errors, oversights, etc.
> >
> >That's a bit strong, there are definitely cases where testing can be
> >exhaustive, e.g. in checking out a sqrt routine for IEEE short form
> >arithmetic. Indeed it is almost practical to do exhaustive testing on
> >long format division (which would have saved Intel many millions of
> >dollars :-)
>
> There are 2^128 different possible divide operations (each operand
> having 2^64 different possible values) - and that's assuming that you
> don't have to test each pair of operands for each possible value of
> the exponent and sign (in which case there are nearly 2^160 different
> operand pairs - each operand having 2^80 different values).  Now,
> assuming that a Pentium class machine can test 100 million operations
> per second (an overestimate to say the least), it would take over 10^30
> seconds to test all 2^128 divides.  This still assumes you have an
> independent source of the correct answer for each divide to test
> against!  Running, say, 1000 machines in parallel, each testing different
> divides, would reduce the time needed to "just" 10^27 seconds.  A
> year has on the order of 3*10^7 seconds.
>
> Now, there are other kinds of tests.  A "correctness proof" is a test
> which does not work by actual execution of the code or hardware,
> but by logical examination of the components of them.  This is still
> only a test, since the "proof" has the same complexity as the thing
> being tested - and the same likelyhood of error.  However, to a
> certain extent, such errors are independent of the errors in the actual
> code or hardware (not always: especially in cases where the "proof"
> is generated with automated tools, an error in one can be completely
> transcribed into the other).  This makes it a useful exercise, especially
> for mission-critical code or hardware.
>
> --
> J. Giles


Note that I said "almost" in my post (having given an example for which
exhaustive testing most certainly is possible). The point in the divide
case is that, given a knowledge of the underlying algorithm and table
look up approach, it is not necessary to test all bit combinations to
get at least full path coverage of the underlying algorithm. This is
not exhaustive testing, but in this case, it is something close, hence
my almost.

And please note I am not saying that path testing in general is the same
as exhaustive testing, just that it is close *in this specific hardware
case*

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own