Constructors motion
P1788 members
In the next day or two I expect to circulate to you, after the Officers have had a chance to comment, a draft of most of the description of Level 1 (omitting the decorations material and some lesser items), asking you to vote for its acceptance as standard text.
It also contains a revised clause 4 "Structure of the standard in levels", to help refresh our memory of what the levels mean.
Included in the Level 1 text but excluded from the vote, and called "provisional", is the following specification of *constructors*. It is very close to what the Vienna proposal has (except Vienna doesn't distinguish Level 1 from Level 2). Separately from the "acceptance as standard text" motion, I hereby submit an (ordinary) motion as below.
I have a query however. When a constructor call "fails", should the call
(a) return Empty, as currently written;
(b) return a "Not an Interval" value, which must then exist at Level 1; or
(c) not return any value, i.e. the function is simply undefined at this input argument?
E.g. text2interval("rubbish").
John Pryce
Motion
======================================================================
The standard shall specify constructors at Level 1 as described below.
======================================================================
Proposed Level 1 text on Constructors
-------------------------------------
> The following operations shall be provided, that create an interval from non-interval data.
>
> The operation nums2interval(l,u), where l and u are extended-real values, returns the set {x in R | l <= x <= u}. If (see subclause 5.2) the conditions l <= u , l < +oo and u > −oo hold, this set is the nonempty interval [l,u] and the operation is said to succeed. Otherwise the operation is said to fail, and returns Empty.
> Success and failure are used in specifying how decorations are set by the corresponding finite-precision operations on decorated intervals.
>
> The operation num2interval(x) is equivalent to nums2interval(x, x). It fails if and only if x is infinite.
>
> The operation text2interval(t) succeeds and returns the interval denoted by the text string t, if t denotes an interval. Otherwise, it fails and returns Empty.
>
> [Note. Since Level 1 is mainly for human-human communication, any understandable t is acceptable, e.g. "[3.1,4.2]" or "[2\pi,\infty]”. Rules for the strings t accepted at an implementation level are given in the Level 2 Subclause 6.11 on I/O and may optionally be followed.]
-------------------------------------
I won't give a Rationale, because the above seems self-explanatory, but it may help to say that in the Level 2 text I aim to circulate shortly, the finite-precision constructors are specified roughly thus:
A. There shall be a version of each Level 1 constructor for each supported or available interval type T, explicit or implicit, and it shall return the T-interval hull of what the Level 1 constructor returns.
B. Until we have sorted out decorations I can't say whether finite-precision constructors shall return a bare or a decorated interval, or whether both kinds exist. I have sympathy with Dan Zuras' view that only decorated interval constructors should exist.
C. The Level 2 Subclause 6.11 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.