Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion P1788/M0030:Constructors NO (was M0031...)



On 2012-05-01 15:12:33 +0100, John Pryce wrote:
> The motion text uses the phrase "... it is undefined" twice in
> specifying these. Someone (I've mislaid the email) recently pointed
> out that "undefined" has two clashing meanings:
> (a) a mathematical meaning: "the function returns no value for this input",
> (b) a standardese meaning: "no behavior is specified, so
> implementers can do what they like".

In fact I think that both meanings are similar at Level 1, because the
actual implementation will be at Level 2. There is no real behavior
(in a standardese meaning) at Level 1, because there is no Level 1
implementation, just specification that will be used by Level 2. At
Level 2, possible behaviors of an implementation of a function are:
  * The behavior is specified by the standard.
  * The behavior is specified by the implementation (this can be
    required by the standard).
  * The behavior is not defined by the standard (and is not required
    to be by the implementation).
By behavior, it can be a return value, some well-specified trap or
something similar. I wouldn't count "anything can occur" as a defined
behavior. "The function returns no value for this input" doesn't make
any sense at any level for the implementation. Saying that the output
is undefined is like saying that the behavior is undefined. Note that
the concept of undefinedness can depend on the language.

> I wish to make clear that (a) is meant. The behavior is specified,
> and it is "there is no value". So I aim to change the Level 1 text
> to make this clear, probably by changing "undefined" to "no value"
> where appropriate and adjusting the grammar as required. And add an
> item "no value" to the Definitions.

This is unclear. Does "no value" means something like undefined (the
standard doesn't specify any value) as above, or is it seen as a
special element of some set (like NaN for Level 2 floating-point).
I think it should be the former, the actual specification being done
at Level 2 (e.g. with particular rules and default rules), as you
seem to say below:

> My idea is that returning "no value" at Level 1 should by default
> imply returning NaN at Level 2 for a numeric return-type, and a
> suitably decorated interval result (that I persist in thinking of as
> NaI though there may be several kinds of it) for an interval
> return-type. "By default" means that any other behavior must be
> decided explicitly by the group, by passing a motion.

> >   I am also reticent to approve use of NaI unless better mechanisms are
> > impossible to use (e.g. constructors that throw exceptions, which will
> > never cause "invalid" intervals to be constructed, which eliminates the
> > need to check for NaI everywhere else in code, which is a potentially
> > large savings in code complexity and performance.)
> 
> I find such arguments puzzling. If floating point standardizers had
> followed them they would never have invented NaN, whose benefits,
> despite Dan Zuras' criticisms, far outweigh its disadvantages IMO.
> We should be envisaging hardware, not software, implementations of
> the five basic interval operations (at least) -- for which "checking
> for NaI" carries negligible overhead. But there are wiser people
> than I to argue the pros and cons of this.

One problem is that there may be languages without traps (in ISO C, I
think that only the notion of signal could be used, and in practice,
I don't think this is better than exceptional values). P1788 might let
the implementation choose.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)