Re: Basenote drift to the value of mid-rad forms...
Dan Zuras Intervals wrote:
If you feel the need for a motion to decide the issues about not infsup
matters beyond what is in Motion 16, you can copy part of the Vienna
proposal, make it fit the structure delineated by the motions already
passed, discuss the result with me if you like, and then turn it into
a motion.
You quote the relevant passages but not how you
would change them to accomplish what you seek.
How would you do that?
I don't want to change them. They express precisely what I want
from the standard, except that the language is not wuite what
evolved through the motions.
It takes time. Writing a document may be done
all at once by a lone author. But getting a
large group of people to agree to all its
details is an incremental process.
Trust that if it looks incomplete to you today,
it looks incomplete to everyone else too. We
will get it working step by step. No need to
condemn one step because the next is not there
yet.
This wasn't meant to be a critique of the current state of the
standard text, but an indication of what would need to be done
to turn the Vienna proposal text relevant to the current issue
into a motion. (The text below is a shortcut that avoids specifying
the details.)
I don't think midrad deserved first class status.
Fair enough.
Still, I hope we agree that motion 19 separates
inf-sups (explicits) from mid-rads (implicits).
but at the unacceptable cost of allowing a midrad-only implementation
to conform to the standard.
Take this away from the motion and it is relatively harmless,
though it unnecessarily complicates the writing and the understanding
of the standard.
What I want to say is that to
conform to the standard you must provide a very
stringent explicit implimentation (which we can
specify today) or a very stringent implicit
implementation (which we cannot yet specify).
This is _impossible_ to specify in a way that it can satisfy the
requirements of any application that needs box splitting. This
includes most current uses of intervals for applications to real
life problems.
A branch and bound code that has to work with midrad-only arithmetic
will have to cover the region close to an interior corner of a box
in the worst case an exponential number of times, unless the box
boundaries are verycarefully selected. This worst case is attained
if the solution sought actually lies in this area - it must then
be found exponentially often!
To have an advantage in speed or memory over infsup, one can allow
only a few bits for representing a radius, which plays havoc with
accurately representing simultaneously innocent intervals such as
[-1,10]. Thus splitting the interval [-22,10] in the middle leads
to double counting of a significant interval near -1.
In multiple dimensions, this effect magnifies exponentially.
Nothing at all has been thoroughly explored about the consequences of
being forced to use midrad-only arithmetic in conventional interval
algorithms, since nobody has been using it in the past.
Not even inclusion monotony is guaranteed anymore in finite-precision
arithmetic since there is no unambiguous concept of hull.
(The requirement of a _particular_ hull, as suggested in the motion,
would select an artificial one. I doubt whether one can easily specify
a practical midrad scheme that makes everything inclusion monotone.)
Therefore a standard that allows a conforming midrad-only implementation
requires _all_ past algorithms to be reanalyzed for their effects
with such an implementation.
One can't rely on _anything_ anymore when switching between different
implementations, one supporting infsup and one supporting midrad-only.
It is difficult to imagine a worse service to the interval community.
I want to avert the damage that a standard with the features proposed
in Motion 19 would do to later users.
And the mid-rad folks may or may not be able to
work things out, as you suggest. If they do,
fine. We put it in the text. If they don't,
also fine. Eliminating them from the standard
is easy to do once they are a separate object
with separate text to be deleted.
But as it is now, the motion completely changes the form and
content of Motion 16, introducing a terminology that only makes
sense if they are successful (which is unlikely given what they
produced within the last two years).
It does. New motions often modify old ones as
our understanding & approach changes. Get used
to it. It will happen a lot in the coming years.
But the understanding hasn't changed.
There has not been a single constructive advance in midrad
theory or implementation to what was known already at the end
of 2008 -- long before Motion 16 was discussed and passed.
But we get in motion 19 part of what you seek.
We split off all discussion of mid-rads from any
discussion of inf-sups.
No. We get multiple idatatypes, which increases the formal
complexity of the standard, and we get the option of midrad-only,
which is the worst part of the motion.
Well, I think of it as separating those notions
rather than multiplying them.
The really bad thing is that it does not just separate them
but allows one to be _replaced_ by the other.
And mid-rad (or implicit) only would only be bad
if the implicits themselves turn out to be bad
in the end. If so, they can go. But I think
they deserve a shot at proving themselves.
I see you do not.
They should prove their point _before_ it is made part of a motion.
Only _then_ is the right time to offer the free shot.
There is little point in opening the gates for anything that
hasn't proved yet its broad utility but might possibly lead to
an improvement after enough new research.
Why make an exception for midrad?
Is that not in keeping with your wishes?
Not at all. We don't get anything of what I seek.
But we undo Motion 16 which was in the right direction.
If not, what would you have us do?
A possible motion text could be:
The standard should not support a midrad interval format or
nonstandard intervals, beyond providing conversion support,
approximately to the extent specified in the Vienna Proposal.
Shall I make that motion for you?
Not for me. I'd be happy with the already accepted Motion 16
taken seriously, and Motion 19 (which flatly contradicts Motion 16)
withdrawn.
But if you or someone else thinks it beneficial for a solid future
standard, and for saving the committee lots of extra work, a motion
text like
The standard shall not support a midrad interval format or
nonstandard intervals, beyond providing conversion support,
approximately to the extent specified in the Vienna Proposal.
looks fine from my perspective.
Arnold Neumaier