Re: Motion P1788/M0030:Constructors NO (was M0031...)
Alan, and P1788
On 18 Apr 2012, at 00:20, Alan Eliasen wrote:
> I vote NO on this proposal. In order for me to vote YES, the motion
> would need be changed to provide clearly defined behavior in several cases:
I'm assuming this is about about Motion 30, despite the subject line.
> * When the conditions for nums2bareinterval(l,u) are not correctly
> specified.
>
> * When the string passed to test2bareinterval(t) is not accepted.
>
> The standards must give defined behaviors in these cases.
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".
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.
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.
Regards
John Pryce