Re: M0019.01 Explicit/Implicit WITHDRAWN; M0019.02 submitted
John Pryce wrote:
[...] I hereby withdraw the motion and resubmit it as Motion 19.02 with the
attached revised position paper
(version 5).
The revised version is significantly stronger (and hence more useful)
that the first version. In particular, by requiring a supported infsup
type (3.5.3), the main defect of the first version is cured.
But it still has a number of items that need improvement.
See the details below.
Irrespective of all the suggestions I make to improve this motion,
and even when these are taken into account, I still recommend against
voting for Motion 19.02, in favor of simplicity and robustness.
Arnold Neumaier
========================================================================
3.1/l.4: this finite set must be required to include the intervals
Empty and Entire.
/l.12-13: B must be a set containing zero, infinity, exactly one
negative number, and otherwise only positive numbers. [I'd also replace
the variable b by r, but this is a minor issue.]
3.5.3: As Michel Hack already mentioned, it should say here
''explicit inf-sup''.
4.1/l.2-3: (b) Note that the main argument brought forward in favor of
midrad arithmetic, namely its use as an intermediate format for fast
vectorized interval matrix multiplication, is inconsistent with
requiring multiplication to be tightest since it overestimates the
radius by up to 50%.
/l.3: I don't see why the proposal achieves much significant
with respect to the reproducibility of results of implicit idatatypes.
Without the requirement on that interval operations are tightest,
reproducibility is not guaranteed. But requiring interval operations
to be tightest beyond add and subtract excludes the most time-efficient
version of midrad arithmetic, namely using Henrici's centered
arithmetic.
/l.6: An infinite radius must be present; on the other hand, an
infinite midpoint may not be present. The formulation must account for
both which it presently doesn't.
/l.7-9: Once this is allowed, reproducibility is indeed impossible.
Therefore decisions such as these must be made on the level of the
idataype and not on the level of its implementation. To emphasize that
this is not acceptable, ''is'' on line 7 should be "were''.
On the other hand, allowing the idatatype definitions on this matter
to vary between otherwise very similar choices is unwise. To avoid
endorsing a multitude of slightly different implicit idatatype variants,
the standard should define explicitly which idatatypes are eligible for
support.
For example, for midrad, I think that the only sensible hull definition
that can claim some sort of superiority among all possibilities is the
one that resolves ambiguities in favor of the absolutely smallest
midpoint. This ensures that overflow does not result in a meaningless
infinite midpoint but produces a unique Entire with zero midpoint and
inifinte radius. It also eliminates the worst finite-precision
anomalies.
/l.13-16: For LIA, see http://en.wikipedia.org/wiki/ISO/IEC_10967
and references there. I think part of the success of the IEEE
floating-point standard was also that it began with standardizing the
most pressing things first (only the binary standard), and then
enlarging its scope with subsequent standards. We should be wise and do
the same, rather than trying to standardize everything at once, with
many half-baked decisions resulting.
5.8/l.2: ''available'' should probably be replaced by ''supported''.