Re: YES on Motion P1788/0019.01
Dan Zuras Intervals wrote:
Date: Sun, 12 Sep 2010 20:07:52 +0200
From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
If the motion allows an implementation to conform to the standard
if it has no infsup datatype, how can the standard require, say,
the following two items:
(i) provision of support for [0,inf] without overestimation
(ii) a square root evaluation that is tightest
(both very sensible and important requirements in the context of
applications to solving constrained nonlinear systems and global
optimization)?
It is even difficult to motiviate why one should prescribe this just
for an infsup implementation if provided, since the standard then
makes very different requirements for infsup and midrad.
Essentially, a standard modelled after this motion but restrictive
for infsup must be of the form:
(a) for infsup, require a lot,
(b) for midrad require almost nothing
(b) is necessary since there is neither theory nor practice that
can tell what would be meaningful requirements in this case).
I hope the majority of voters is rational enough to vote in a way
that serves those having to live with the standard in the future,
rather than voting to avoid dissens with a few who want the standard
to reflect issues that in the past (and for good reasons0 never had
enough life blood to lead to a serious implementation.
You point out that an imlementation that conforms to a
standard that follows this motion must either
(a) conform to a form that is explicit for which inf-sup
forms easily qualify & about which we can say much that
is sure, or
(b) conform to a form that is implicit for which mid-rad
forms qualify & about which this motion has little to
say because we don't quite know what we can say that is
sure yet.
As opposed to a standard that does not follow this motion
about which we must either
(a) say very little about how either form conforms, or
(b) exclude mid-rads altogether in favor of inf-sups.
So it is failure to pass this motion that threatens to
either gut the standard or eliminate mid-rads, not the
reverse.
No.
Motion 16, which passed already, does not eliminate midrad,
but midrad-only. It leaves completely open what afficionados
of midrad can produce as goodies, if they also provide an
implementation of infsup that is satisfying.
In my opinion, the latter is a condition without which a standard
fails to achieve its main purpose, namely to put the support for
intervals for _general_ use on a safe basis.
The present motion steps back from Motion 16, and allows a midrad-only
implementation to conform to the standard. Because of the only weakly
developed theory and practice of midrad arithmetic, a standard allowing
midrad-only can hardly be significantly more restrictive than to require
correct enclosure, or it makes a conforming implementation either
impossible, or possible only according to a very specific design
created from scratch for the purpose of the standard, and - being not
widely tested by users - likely to be poor.
Moreover, such an implementation, while standard-conforming, would be
useless for those applications which currently have the most impact
outside the interval analysis community.
We can go as you please but I prefer to consider the
possibility that mid-rad forms have merit.
The merits are such that no one in the last 50 years was moved by
them to create a serious implementation, although the ideas were around
as long as those for infsup.
It is very unwise to cater in a standard for possibilities that
haven't already left a strong trace in the past, and without having
even a blueprint (position paper) on how such a possibility should
be fleshed out.
Just how
we are to restrict their behavior in any meaningful
way is the subject of some future motion written by
those who know this subject far better than I.
Let's see what they come up with rather than assume
their failure from the beginning.
Motion 16 required infsup and allowed midrad as additional type.
It was proposed by you and found a majority.
Passed motions should not be undone without _very_ strong reasons
for doing so.
Why did you change your mind?
It is much better to stay with motion 16 until those who know
this subject far better than you have come up with some convincing
details on how we are to define midrad-only behavior in a way that among
other things, in particular (i) and (ii) are catered for.
If a strong proposal along these lines is made (which I consider very
unlikely), it is still possible to relax Motion 16 at that time.
But it is irrational to do it without having evidence that it would be
an improvement of the standard-to-be.
Arnold Neumaier