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 19:26:07 +0100
> From: "N.M. Maclaren" <nmm1@xxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: rbk@xxxxxxxxxxxxx, Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>,
> 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:
> >> From: Ralph Baker Kearfott
> >>
> >> Do I have a second for this position motion?
> >
> > I have difficulty with the language of this position paper.
> > The expression "Containment-only Interval Standard" suggests
> > to me a specification so loose as to admit an implementation
> > that returns [entire] for all its functions as complying.
>
> That is precisely what all conventional languages I know of do when
> they come to something that is effectively unspecifiable, and often
> when they come to something that is merely tricky or controversial.
> While it is a laudable aim to reach the specification precision of
> the "program proving" and hardware design languages, but for real
> numbers, it is probably infeasible.
>
> The requirement dates from time immemorial (certainly 1960s, and
> perhaps earlier); I have tried doing it and spoken to several people
> who have, over that period, and the one thing in common is that we
> have all retired hurt. I believe that Ada does something along the
> lines of what I mention below, but I haven't looked at it in decades.
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.
>
> > And yet, on further reading, I find that I am wrong & this
> > is NOT what Bill has in mind. I'm not entirely sure what
> > he DOES have in mind but it is clear that he wishes to
> > specify things at level 1 as much as possible.
>
> Without trying to second guess anyone, my opinion is that adopting
> the position is probably the only feasible solution if either the
> specification is to be completed within a decade or if there is to
> be any chance of it being adopted.
>
> There are a few relaxations that can be done, though none are easy,
> and only the first provides actual requirements:
>
> 1) To require implementations to deliver a particular result in
> the few trivial cases.
>
> 2) To require implementations to document the precision of the
> result in the simplest cases.
>
> 3) To provide advisory guidelines on what should be achieved in
> a respectable implementation, again in the simplest cases.
>
> In all cases, it is extremely difficult to specify such things in a
> way that is both useful for programmers and feasible to implement on
> the systems they will be using, even before issues of optimisation
> arise (and then it becomes truly evil, both technically and politically).
>
>
> Regards,
> Nick Maclaren.
Nick,
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.
This is a workable & testable specification & is, at least
for the basic operations, identical to OUR specification.
Issues of the result of complicated expressions or whether
or not the implementation in question has a higher
precision available for intermediate results remain. But
he seems aware of this & touches on it elsewhere in his
text.
In short, while I do not think this position paper embodies
a workable specification, I don't believe that was intended.
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.
(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,)
(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.)
(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?
Dan