Re: Constructors motion
> Subject: Re: Constructors motion
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Sat, 17 Dec 2011 08:04:56 +0000
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>,
> George Corliss <george.corliss@xxxxxxxxxxxxx>
>
> 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.
Please forgive a naive question but can someone tell me
why Kaucher intervals are excluded?
Is it just the lo <= hi thing or is it something more
subtle?
Remember to couch your answer to the non-interval guy
on the list. That is, speak slowly & use small words. :-)
>
> 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".
So is it well understood at this point that excluding
Kaucher intervals (at this point) is a GOOD thing?
If they are excluded ONLY for the lo <= hi thing, can
they not be included by a Kaucher decoration which
reverses that?
Again, this is the dumb guy asking.
>
> 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!
Again, from the naive corner, if the rule that excludes
Kaucher is only lo <= hi, can this not be extended
without conflict by having a Kaucher decoration on an
otherwise ordinary (read: conforming) interval?
>
> 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
OK, its beginning to sound to me like lo <= hi is the only
objection.
If that is so let me suggest a simple approach for decorated
intervals.
A constructor for a decorated interval
xx = makeInterval(lo,hi,decoration);
constructs the decorated interval xx = {[lo,hi],decoration}
iff (lo <= hi && Kaucher not \in decoration) ||
(lo >= hi && Kaucher \in decoration) otherwise it returns
xx = {[empty],invalid}.
Its simple &, if I understand the problem, it works every
time.
Of course, given that its unlikely that I really DO
understand the problem, it is likely silly.
But this is not why I replied to this note. :-)
I was thinking about Nate's discussion of the levels of
both decorated & bare intervals. Now this may ALSO sound
silly given that we are currently voting on a kind of
level 1 & 2 standard only, bbbbuuuutttt in all our
discussions of bare intervals the justification for them
has always been one of optimization. That is, bare
intervals are justified because they improve the memory
arrangement of intervals (to powers of 2, say) or they
eliminate the time & effort of calculating the decorations
when they are not needed or some combination of these
things.
Given that justification, it seems to me that bare
intervals belong at level 3. Thats where optimizations
live.
However, this might become inconvenient should we decide
not to say anything about level 3.
Therefore, let me suggest that we make an exception for
bare intervals. That is, we go ahead & define them as
level 3 objects & talk about when they should be used &
why. Since that discussion is about optimizations, it
is naturally a level 3 argument.
Nate, I suspect this may be at odds with what you have
in mind. So I'm most curious how you feel about this
suggestion. If it makes no sense at all let me know &
I'll drop it.
But, for the moment, it seems like it makes both jobs
easier.
Just my naive $0.02 worth...
Yours,
Dan