Second:
Arnold's comments.
On 16 Sep 2010, at 11:48, Arnold Neumaier wrote:
Ralph Baker Kearfott wrote:
I think motion 19 was meant to be a compromise to maintain some level of
simplicity while providing minimal specifications to other arithmetics
that may be common. The committee needs to decide whether or not
we need to do that and whether or not motion 19 accomplishes that.
More importantly, the committee needs to decide whether or not
a standard that does not support the most widely used applications
of interval techniques is a standard worth having.
The main thing that Motion 19 accomplishes is to compromise the standard
to an extend that it becomes useless for general global optimization and
for rigorous solution of nonlinear systems in unbounded domains,
by allowing a midrad-only implementation to conform to the standard.
Arnold gives a persuasive argument. And yet, is it ... ?
The fact that a standard permits implementations that are useless for a
particular application does NOT make the standard itself useless. One
should apply some common sense. Here's two examples.
- IEEE754-2008 only requires conforming implementations to
support ONE of the five basic formats
binary32/64/128, decimal64/128.
An implementation in some embedded system may only support
binary32. It's conforming, although it's of little use for
solving large ODEs or large linear algebra problems. Another
implementation may only support decimal128. I can't for the
life of me think why, but it would be conforming.
- Look at Fortran (90/95)'s requirements for floating point
(REAL) types. All it says is that there shall be a default
type, and a type of higher precision than the default. Fortran
specifies neither the exponent range nor the precision of
either of these. A conforming implementation may support just
a 24-bit "single" and a 32-bit "double" precision, say. We don't
call the Fortran standard useless because it permits such
implementations.
In fact such an implementation may be just what's needed in an
embedded system for which the usual 32 bit single, 64 bit double
is quite inappropriate. Horses for courses.
It is impossible to build upon such a standard a branch-and-bound code
that supports unbounded intervals (needed already in many linear
programs).
The least amendment that must be made to Motion 19 to permit it being
called a compromise (rather than a slap in the face of an important
part of the user community) is to _require_ that at least one explicit
idatatype is supported.
That is implied, if M19 is revised as proposed above to be compatible with
M16.
...
What do people think?