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