From: Stephen Leake <stephen_leake@stephe-leake.org>
Subject: Re: Float conversion
Date: Wed, 04 Aug 2010 03:26:59 -0400
Date: 2010-08-04T03:26:59-04:00 [thread overview]
Message-ID: <82pqxyu9bw.fsf@stephe-leake.org> (raw)
In-Reply-To: 77ee8883-ab9f-42c7-94d5-3d85cdc19693@i28g2000yqa.googlegroups.com
Phil Clayton <phil.clayton@lineone.net> writes:
> On Jul 31, 4:12 pm, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> Clearly to cover all cases, you
>> need A < B, A = B, A > B, A < C, etc.
>
> You make it sound easy...
It is easy! This is a very small program; exhaustive testing is
appropriate.
> Generally, how do you justify that tests 'cover all cases' so giving
> you a 100% chance of finding an error?
There are three inputs: A, B, C.
According to the code, there are three important edge cases for each
pair: A < B, A = B, A > B
If we assume the floating point hardware is correct, we don't need to
worry about any other cases.
So that's nine cases to test, total.
> Note that even if I had test cases that exercise all possible
> orderings of A, B and C, I am not guaranteed to find an error in an
> incorrect implementation of Y = min {A, B, C}. For example, I could
> have chosen positive values for A in every test but the program could
> have contained an extra erroneous condition
>
> ... and 0 < A
>
> that would have gone undetected. So the tests need to take account of
> the particular implementation too.
Ok. I agree this is a white box test that is aware of the code. So add
another set of conditions: A < 0, A = 0, A > 0. Still a small finite set
of tests.
>> > Where does the original justification go wrong? Well, when talking
>> > about 'the smallest' there is an implicit assumption being made that
>> > it is unique. The justification never considers the case when A or B
>> > is the non-unique smallest.
>>
>> And the same error could be made in a formal specification. "formal"
>> does _not_ mean "complete"!
>
> Although I said "formal methods", I use this example to motivate
> formal verification, not formal specification. Any specification,
> formal or not, can be a load of rubbish!
What are you verifying, if not a specification?
If the specification is rubbish, what is the point of verifying it?
--
-- Stephe
next prev parent reply other threads:[~2010-08-04 7:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-29 12:23 Float conversion Henrique
2010-07-29 12:44 ` Jacob Sparre Andersen
2010-07-29 12:46 ` Dmitry A. Kazakov
2010-07-29 15:08 ` Georg Bauhaus
2010-07-29 15:10 ` Georg Bauhaus
2010-07-29 15:35 ` Dmitry A. Kazakov
2010-07-29 18:21 ` Henrique
2010-07-29 19:08 ` Jeffrey R. Carter
2010-07-29 19:15 ` Dmitry A. Kazakov
2010-07-30 1:30 ` Phil Clayton
2010-07-30 8:43 ` Dmitry A. Kazakov
2010-07-30 13:14 ` Phil Clayton
2010-07-30 14:34 ` Dmitry A. Kazakov
2010-07-31 15:12 ` Stephen Leake
2010-08-03 1:07 ` Phil Clayton
2010-08-03 3:31 ` Shark8
2010-08-03 10:38 ` Georg Bauhaus
2010-08-04 7:27 ` Stephen Leake
2010-08-04 16:15 ` Georg Bauhaus
2010-08-04 16:32 ` Phil Clayton
2010-08-04 7:26 ` Stephen Leake [this message]
2010-08-04 12:52 ` Robert A Duff
2010-08-04 14:32 ` Dmitry A. Kazakov
2010-08-04 19:36 ` Simon Wright
2010-08-04 19:46 ` Dmitry A. Kazakov
2010-08-04 20:29 ` Georg Bauhaus
2010-08-05 12:05 ` Stephen Leake
2010-08-07 5:54 ` Shark8
2010-08-07 8:56 ` Georg Bauhaus
2010-08-07 13:49 ` Shark8
2010-08-05 10:20 ` Phil Clayton
2010-07-30 13:16 ` Henrique
2010-07-29 15:37 ` Warren
2010-07-29 14:56 ` Georg Bauhaus
2010-07-29 17:56 ` Jeffrey R. Carter
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox