From: Georg Bauhaus on
On 04.08.10 09:27, Stephen Leake wrote:
> Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes:
>
>> On 03.08.10 03:07, Phil Clayton wrote:
>>
>>>> Clearly to cover all cases, you
>>>> need A < B, A = B, A > B, A < C, etc.
>>>
>>> You make it sound easy... Generally, how do you justify that tests
>>> 'cover all cases' so giving you a 100% chance of finding an error?
>>
>> When {A, B, C} in (machine) Float, I guess "<", "=", and ">"
>> won't tell the whole story in any case?
>
> Why not?
>
> Those are the only conditions tested in the code.

Suppose the code has, for a reason, the conditional

if A = A then
else
end if;

That one can be important, J.-P. Rosen recently explained why,
talking about NaN. Is this test usually present?

Then, as Dmitry said, comparing Inf needs special care. The meaning
of predefined "=" in some test case, for some floating point type,
can depend not just on platform, but also on platform state.
Practically, GNAT has, or used to have a state switching subprogram
that would turn on 80 bit FPT when running on Windows NT, IIRC.
Can a test make sure that results of "=" or even of "<" will be
unaffected by state switches in the processor?

What if significant epsilons change as computed results grow or shrink?

Additionally, can one write a test for ARM Something and hope
it gives the same result on a PC workstation for the
"same" program?


Georg
From: Phil Clayton on
On Aug 3, 11:38 am, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de>
wrote:
> On 03.08.10 03:07, Phil Clayton wrote:
>
> >> Clearly to cover all cases, you
> >> need A < B, A = B, A > B, A < C, etc.
>
> > You make it sound easy...  Generally, how do you justify that tests
> > 'cover all cases' so giving you a 100% chance of finding an error?
>
> When {A, B, C} in (machine) Float, I guess "<", "=", and ">"
> won't tell the whole story in any case? (If they are assumed
> to mean what they usually mean in "mathematics".)

Yes. Using a mathematical model where floating point values are
viewed as mathematical real numbers (i.e. having infinite precision)
and where operators have their standard mathematical meaning is an
approximation. Reasoning with such a model of programs will detect a
useful and wide class of error but won't correctly predict the
behaviour of programs in absolutely every case. It is easy to produce
examples that demonstrate this involving floating point equality and
values that cannot be represented exactly.

Phil
From: Simon Wright on
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:

> (some things are stateful. A pipelined CPU pipeline definitely is. We
> used to ignore that, can we for "exhaustive" testing?)

If we can't we are all doomed.
From: Dmitry A. Kazakov on
On Wed, 04 Aug 2010 20:36:28 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:
>
>> (some things are stateful. A pipelined CPU pipeline definitely is. We
>> used to ignore that, can we for "exhaustive" testing?)
>
> If we can't we are all doomed.

That reminds me the old programmer's saying: never test for the bugs you
cannot fix.

(:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Georg Bauhaus on
On 8/4/10 9:36 PM, Simon Wright wrote:
> "Dmitry A. Kazakov"<mailbox(a)dmitry-kazakov.de> writes:
>
>> (some things are stateful. A pipelined CPU pipeline definitely is. We
>> used to ignore that, can we for "exhaustive" testing?)
>
> If we can't we are all doomed.

FPT programs are a little more complex to test in full anyway,
so exhaustion is relative :-)

The subject seems to have been on the radar since the beginning:
http://archive.adaic.com/standards/83rat/html/ratl-05-03.html#5.3.1

With notes on "=" and "/=" and whether to provide these
operation at all with Ada floating point types.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: What is your preferred VCS?
Next: GPS 2010 for AVR