Re: Constructors motion
Nate, George and all
On 3 Dec 2011, at 15:01, Nate Hayes wrote:
> I basically agree with your points, too. Although may I also be so bold as to suggest that decorations truly are (or can be) a Level 1 concept, at least as far as *decorated intervals* are concerned. Constructors in this sense can be viewed as an interval function that simply takes non-interval arguments. This means at Level 1 constructors have a natural domain. So (Empty,ndf) for invalid construction is the same as returning (Empty,ndf) for an operation like f(xx)=1/xx when xx=[0,0] because [0,0] is not in the natural domain of f.
>
> In the interest of moving forward and making progress, though, and since decorations are still yet to be settled (and controversial), I don't have any problem to say that for *bare intervals* an invalid construction simply returns Empty. This is what Motion 5 does, for example, which says that for bare intervals 1/[0,0] = Empty.
>
> Nate
>
> P.S. I still would not use such a standard in my own software and/or hardware products, though, since the motion as currently worded specifically causes an implementation using Kaucher intervals to be non-conforming.
I basically agree with what Nate writes. As for his P.S.: "specifically causes ..." is inevitable *at some point* in the standard, because Kaucher intervals are different. I had always assumed (I think this is explicit in some of our correspondence right at the start of the project) that there will be a separate clause of P1788 called something like
"Extensions and changes to the standard for Kaucher intervals".
Conceptually it will comprise two disjoint sets of specifications:
Kextend = {specifications that extend those of the main standard},
Kcontra = {specifications that contradict those of the main standard}.
It may not be easy to allocate a given spec to one of these. It may require careful wordsmithing. It requires us to define the term "extend" carefully.
One of the group's aims should be to word the main standard so that *the sets Kextend and Kcontra are as small as possible*, but they cannot be empty!
For a bare interval constructor yy = nums2interval(a,b) the *main, Level 1*, standard has 2 obvious choices for the pre-conditions, in the cases where the inputs a,b are both non-NaN, and independently 2 choices for the result:
M1. a and b are extended-real values, not both infinite of the same
sign, such that a <= b. Then yy = [a,b].
If this condition is not satisfied, yy = Empty.
M2. As M1, except if this condition is not satisfied, yy is undefined.
M3. a and b are extended-real values, not both infinite of the same
sign. Then yy is the smallest interval containing both a and b.
If this condition is not satisfied, yy = Empty.
M4. As M3, except if this condition is not satisfied, yy is undefined.
A Kaucher spec must be different from all of these. Nate, please correct me, but I think it could be (recall this is Level 1, for bare intervals)
K1. a and b are extended-real values, not both infinite of the same
sign. Then yy is the Kaucher interval [a,b].
If this condition is not satisfied, yy is undefined.
We might allocate it to the set Kcontra. But one can argue it does everything that M2 does, and more, in which case it belongs in Kextend. Hmm, "extend" is a tricky concept.
Does this approach make sense?
John