Re: Constructors motion 30 Version 2.
P1788 members
There's still work to be done responding to comments on the Level 1 draft text, but I really need to revive the Constructors motion 30, so here goes.
Motion 30 V1 was proposed on 3 Dec 2011. I have been slow to amend it in the light of comments. Here at last I submit V2, taking various comments as friendly amendments. It is very much rewritten.
My main considerations are as follows. The fact that we haven't yet agreed the decoration system raises a small difficulty, but I think I handle it.
1. I have become more convinced that *at Level 1* an operation, at input(s)
where it does not have a natural value, should simply be undefined -- in a
Level 1 algorithm "f is undefined at x" makes unambiguous sense. I think
Vincent agrees, maybe others. Of course, at the implementation levels, a
value must be returned.
2. I agree with those (Arnold, Dan, ...) who say there should only be
constructors of *decorated* intervals, not of bare intervals. This makes
constructors secure by default, in the sense that if a programmer wants to
discard a decoration that signals construction failure, they must do so
*explicitly*.
3. Any decorated interval resulting from construction failure I'll call a NaI.
(Not "the NaI". I agree with Nate there may be various flavours.) For now, I
assume the interval-part of any NaI is Empty, but that's a design decision,
not an essential. I'm skeptical of arguments such as Vincent (2012 Jan 4)
(a) ... if nums2interval(l,u) fails, i.e. in the case l > u
or l = +oo or u = -oo, then { x in R | l <= x <= u } is still
mathematically defined and is the empty set.
The semantics might have been defined as
(b) "the intersection of the reals with the smallest extended-real
interval containing l & u",
which makes nums2interval(3,2) = [2,3]. Or
(c) alter "containing l & u" to "containing those of l & u that are
extended-real numbers" (like 754's usage of max and min), which makes
for instance, nums2interval(3,NaN) = [3,3].
All of (a,b,c) are bad design IMO. Constructors should be maximally
unforgiving, with the smallest domain in the Level 1 sense (= set of "OK"
inputs) needed to provide the desired facility. This makes it more
likely programmers are forced to think about what they really want.
[E.g. suppose u decreases below l in nums2interval(l,u). In a Kaucher
system that can be regarded as happening nice and continuously, but
*not* in a set-based system. Does the programmer really want Empty in
this case? A constructor error is best IMO.]
I think, independently of the decoration system, I can express my purpose as follows. A Level 1 interval constructor first constructs a bare interval. If this succeeds, it gives the appropriate decoration for a new interval. Otherwise, it returns a NaI: a decorated-interval value that tells you "construction failure", and maybe (TBD) what kind of failure.
Comments please on the general thrust of the approach. Also please say, e.g., if there are needed constructors that I have forgotten.
I seem to recall Arnold had interesting ideas on combating the problem of a programmer writing num2interval(0.1) when what's needed is text2interval("0.1"). Arnold, I've lost this, please remind me.
Regards
John Pryce
======
Motion
======================================================================
The standard shall specify constructors at Level 1 as described below.
======================================================================
-----------------------------
Specification of Constructors
(Only approximating to actual text, since there is some "meta-description" in it.)
-----------------------------
An (interval) constructor by definition is an operation that creates a bare or decorated interval from non-interval data. The following Level 1 decorated interval constructors are defined, which shall have Level 2 versions as specified in <<suitable place in Clause 6>>.
A NaI by definition is a decorated interval value that can never be the result of a successful construction, and is used to signal a construction failure. What NaI values exist will be decided by a later motion on decorations, but there must be at least one.
The decorated interval constructors are defined in terms of the following bare interval constructors, which are "virtual" since they have no Level 2 counterparts in the standard.
- The constructor nums2interval(l,u) is defined for a pair of extended-real
values (l, u). If the conditions l <= u , l < +oo and u > -oo hold, its
value is the nonempty interval [l,u] = {x in R | l <= x <= u}; otherwise it
is undefined.
- The constructor num2interval(x) is equivalent to nums2interval(x, x).
- The constructor text2interval(t) is defined for text strings t. If t denotes
an interval according to some predefined syntax, its value is that interval;
otherwise it is undefined.
[Note. Examples of suitable text strings t might be "[3.1,4.2]" or "[2\pi,
\infty]” or "Entire". Since Level 1 is mainly for human-human communication,
the standard does not specify a syntax for t at Level 1. At Level 2, the
syntax for acceptable t is given in <<the subclause on I/O>>; this may
optionally be followed in a Level 1 algorithm.]
- The constructor empty() returns Empty.
- The constructor entire() returns Entire.
The decorated interval constructors nums2decinterval(l,u), num2decinterval(x), text2decinterval(t), decempty(), decentire() are defined as follows. If the value xx of the corresponding bare interval constructor is defined, then the decorated interval constructor is said to succeed, and returns (xx,d) where d is appropriate, in the decoration system, for a new interval with the value xx. Otherwise it fails, and returns a NaI as determined by the decoration system.
[Example. In a decoration system based on Arnold Neumaier's approach, (xx,d) equals domain(xx).]
-----
Notes (slightly changed from V1)
-----
A. In the Level 2 text, I propose to specify the finite-precision constructors roughly thus -- a small modification of what I wrote before, to handle the decoration aspect, which was missing before.
There shall be a version of each Level 1 decorated interval constructor
for each supported or available interval type T, explicit or implicit.
It shall return the T-interval hull of what the Level 1 constructor
returns, if the latter succeeds. Otherwise it shall return a NaI value
with the same meaning as that returned by the Level 1 constructor.
B. The Level 2 Subclause referred to above describes "the strings t
accepted" thus:
- Vienna section 6.2 square brackets form, like "[3.4e1, 5.6e1]", is required
(to be accepted).
- The strings "Empty" and "Entire" are required, also "empty" etc.
- Vienna 6.3 "Centered intervals", like "<2.3+-0.005>", are recommended.
- Vienna 6.4 "Uncertain numbers", like "1.23_" and "1.2?e3", are recommended.
- Vienna 6.5 "Exact numbers", like "-5/7" and "0.71428" and "Pi", are required.
- Vienna 6.6 and 6.7 look excellent but I haven't a view on them yet.