Re: Some thoughts on Motion 19 (still under vote)
Arnold, P1788
First:
It has been pointed out that the Motion 19 position paper (M19 for short) contradicts M16.
This seems to be true, and was an oversight.
- I guess the 2nd clause of "proposed revised Conformance requirements" in 3.4 of M19 is not compatible with M16's requirement "a conforming implementation shall support at least one inf-sup type".
- Does the group see any other incompatibilities?
Chair, what to do? Must Dan and I withdraw the motion and resubmit after revision? Or can we make a "what we really meant was..." statement, and the group continues the vote? (I think in a face to face meeting that would be allowed.)
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.
Third:
private discussions have convinced me that the "text string" part of M16 needs hardening up. See also 3.4.3 of the I/O motion 17. I think for EVERY idatatype, whether "supported" or "available", there should be a way to export (write) it to a text string that is (a) exact, (b) human-interpretable, and (c) can be imported (read) back again.
That is, if s=Wx writes interval x to string s, and x=Rs reads back, then the "exact export" function obeys
RWx = x for all x in the idatatype.
Humans can then verify the exactness by writing it out again and checking WRWx = Wx.
For instance, a mid-rad type stored as two binary 754-conforming FP numbers might be exported to string
<midpoint> +- <radius>
where <midpoint> and <radius> are numbers in the hexadecimal-significand form of 754§5.12.3. Implementers of exotic types would be responsible for inventing this "human-interpretable" form, which is essentially a mathematical description of the idatatype that is also machine-readable.
What do people think?
John Pryce