Re: Do I have a second? Re: Position: That the Standard for Computing with Intervals Have Only One Level 1 Requirement: Containment
> Date: 03 Aug 2011 21:13:18 +0100
> From: "N.M. Maclaren" <nmm1@xxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Do I have a second? Re: Position: That the Standard for Computing
> with Intervals Have Only One Level 1 Requirement: Containment
>
> On Aug 3 2011, Dan Zuras Intervals wrote:
> >
> > If, by this, you mean that no specification beyond the
> > fact of containment has been the standard up until now
> > & that we should not have it as a standard going forward,
> > I agree.
>
> That is what I mean, except that I am referring to the actual
> requirements, and not necessarily to recommendations.
>
> > I am struck by this sentence from Bill's position paper:
> >
> > The one and only level 1 implementation requirement
> > must be to enclose the smallest set of values (the
> > containment set) that must be contained in the
> > interval result of any evaluated arithmetic
> > expression or function defined therefrom.
> >
> > While I might use less tortured prose, it sound to me like
> > the specification he desires is to return the tightest
> > interval that the working precision permits.
>
> In which case I misunderstood its intent! I understood it to mean
> that only containment is required, and the actual size of the interval
> is not a requirement (merely a quality of implementation issue). I
> agree that the text is confusing.
Yes, I misunderstood it on first reading myself.
Actually, I must have just glanced at it & nothing
more. Reading it in its entirety is a bit confusing
but it seems to have the intent of specifying something
of high quality.
What that means & how it is specified is unclear.
Thus the need for a discussion. :-)
>
> > This is a workable & testable specification & is, at least
> > for the basic operations, identical to OUR specification.
>
> I disagree that it is either workable or testable, in general.
> See later.
Hmm.
It served our purpose in 754 well enough.
>
> > We could do worse than the principles:
> >
> > (1) If at all possible, express all (shall)
> > requirements at level 1.
> >
> > (2) Specify that all the operations we require
> > return the tightest possible results in the
> > precision available.
>
> That more-or-less forbids optimisation, and begs the question of
> what the precision available is, anyway. This is coming back as
> an important issue with the reinvention of coprocessors (including
> vector units, GPUs etc.) - they don't always behave exactly
> identically to the 'main' CPU.
Now YOU are confusing me here.
It neither forbids optimization nor permits untestably
loose implementations.
And there is no question of the precision available.
It is decided in the declaration of the interval
objects. WhereEVER the CPUs lie.
Or do you have some other issue in mind here?
>
> > (3) Specify that all optional operations ALSO
> > return tightest possible results should those
> > operations be chosen to be part of the
> > implementation. (This leaves it possible for
> > looser implementations of these operations to
> > be hanging around, just not as part of the
> > testable standard,)
>
> That more-or-less means that all serious numeric programs will be
> outside the standard, which rather removes the point.
Well, I must say I don't understand this either.
>
> > (4) Specify that expressions involving these
> > operations return results no worse than the
> > blind sequence written in the source. (This
> > leaves room for improvement along lines we
> > have always considered.)
>
> Er, what IS the blind sequence for anything non-trivial? That
> approach was taken by C99 for complex numbers, and it was and is
> a disaster. Even with as simple an operation as multiplication
> of complex numbers, the 'obvious' code is not the most precise.
Well, let's see...
Off the top of my head:
ff(xx) = sqrt(xx^2) - abs(xx) + 2.
As Nate is fond of reminding us, this should return
the fairly narrow interval [2,2] for all xx.
And yet, implementing the function as written (i.e.
blindly) would result in wider intervals which depend
on xx.
That's what I mean by "no worse than the blind
sequence written in the source".
Such a result should be permitted without excluding
the possibility that a very clever compiler might
figure out that [2,2] is the answer in all cases.
>
> > (5) And, in so far as is possible, have no
> > other specifications than these.
> >
> > This too is not a workable specification for a standard.
> > But it is not a bad set of principles for us to use to
> > decide what IS a good standard.
> >
> > As a guideline only, does this not sound reasonable?
>
> With the reservations above, yes. But those reservations are
> serious.
>
>
> Regards,
> Nick Maclaren.
And with those reservations we have the means
to turn a guideline into a workable standard.
After all, it IS the job we signed up for. :-)
Dan