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.
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.
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.
(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.
(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.
(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.