Re: I vote NO on Motion P1788/M0030.02:Level_1_constructors
Dan and P1788
On 28 Mar 2012, at 06:34, Dan Zuras Intervals wrote:
> This motion defines nums2bareinterval, text2bareinterval,
> bareempty, & bareentire in some detail & then goes on to
> define decorated constructors as something of an
> afterthought.
>
> It is my opinion that bare intervals will be of great
> utility to optimizing compilers to reduce both storage &
> computation for those applications that can PROVABLY do
> without decorations. But I believe it will turn out to
> be poor programming practice for users to create bare
> intervals on their own.
>
> Of course, it must be possible for users to do this. So
> we must provide something like a makeBare. But to provide
> a complete set of operations supporting bare intervals as
> a first class datatype makes us complicit in that poor
> programming practice.
>
> For when the rocket blows up due to some decoration being
> ignored, finding
>
> xx = makeBare(nums2interval(a,b));
>
> in the code makes it the programmer's fault. Finding
>
> xx = nums2bareinterval(a,b);
>
> makes it our fault.
>
> And, as I would rather not be named in a $1 billion lawsuit,
> I vote NO on this motion.
>
> I would vote yes if the bare versions of these constructors
> were removed.
I agree with Dan's basic point that it is best if constructors always make decorated intervals, but either he is looking at different text from my motion, or he is misreading its intention. I copy it below plus note B of the mini-rationale.
The ONLY reason why the motion doesn't define constructors of decorated intervals, explicitly, is that we haven't resolved the decoration impasse yet. The motion doesn't even explicitly say that the constructed interval is a bare one! Please regard this as sort of "virtual" text to become concrete when a decoration system is fixed.
I hope therefore that Dan will change his vote, if the "bare"ness is the only thing that concerns him.
John Pryce
> 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.
(This constructor is now officially removed, by a friendly amendment.)
>> 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.]
>
> -------------------------------------
> ...
> 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.