Re: [boost] [contract] toward N3351 concepts

Subject: Re: [boost] [contract] toward N3351 concepts
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-10-05 13:39:11

on Mon Oct 01 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:

> AMDG
>
> On 10/01/2012 03:43 AM, Andrew Sutton wrote:
>>> Unless you mean to say that any program that uses
>>> a NaN in any way has undefined behavior, this notion
>>> of a "well-formed value" seems arbitrary and capricious.
>> 
>> The notion of "well-formed value" comes for Elements of Programming.
>> NaN is given as an example of something that is not well-formed. It's
>> defined in the first couple of pages, IIRC. Any state of an object
>> that does represent a value (e.g., NaN does not represent a real
>> number) is not a well-formed value. I can assure that neither Alex nor
>> Paul would consider the definition to be arbitrary or capricious.
>> 
>
> Well, I beg to differ.

Yeah, I have problems with the concept of "well-formedness" as well,
because it adds an exception to every statement.  It's not that it's an
invalid way to look at things, but it merely complicates reasoning about
code with no offsetting benefit.  

>> A program that checks for NaN as the result of an invalid computation
>> does not have undefined behavior because it is explicitly checking for
>> that state. A program that uses NaN as if it were a real number should
>> have undefined behavior.
>
> That's no different from saying that a program that uses
> 2 + 3i as if it were a real number has undefined behavior.
> If you make an assumption about the value of an object,
> then it's likely to be undefined behavior if that
> assumption doesn't hold.

+1

>> It is easy to construct examples of programs where NaN breaks the
>> postconditions of STL algorithms:
>> 
>> double s[] { NaN };
>> assert(find(s, s + 1, NaN) == s); // will fail
>> 
>> double s[] { ..., NaN, ... };
>> sort(s, s + N);
>> assert(is_sorted(s, s + N)); // probably fails
>> 
>> Comparisons on NaN do not conform to the usual semantics of equality
>> and ordering, and so the programs have undefined behavior.

Zero breaks the postconditions of division.  So?

> A NaN:
> - Can have various basic operations applied to it
>   with well-defined results.
> - Can appear in program input and output.
> - Can be used safely in some generic algorithms.
>
> Therefore, I maintain that a NaN is a legitimate
> value.  Saying that it is ill-formed depends solely
> on the intent of the programmer in specific
> cases and is not a universal truth.

+1

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost