Float conversion
in [ADA]
|
Prev: What is your preferred VCS?
Next: GPS 2010 for AVR
From: Georg Bauhaus on 4 Aug 2010 12:15 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 4 Aug 2010 12:32 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 4 Aug 2010 15:36 "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 4 Aug 2010 15:46 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 4 Aug 2010 16:29
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. |