On 1 Nov 2010 at 19:17, Arnold Neumaier wrote:
Date sent: Mon, 01 Nov 2010 19:17:13 +0100
From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
Organization: University of Vienna
To: Svetoslav Markov <smarkov@xxxxxxxxxx>,
1788 <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Motion 19.02 NO
Svetoslav Markov wrote:
My vote to motion 19.02 is "no".
I would vote "yes" if either:
a) the motion is modified so that an implementation
that supports only an implicit type is also conforming
b) the name of the interval arithmetic standard is
modified accordingly.
Svetoslav Markov, IMI-BAS
PS. Motion 19.02 makes a significant step towards the
recognition of the "mid-rad" implementations as auxiliary to
"inf-sup". However, I think that "mid-rad only" arithmetic
should also be conforming. Let me recall the two main
mathematical arguments against "mid-rad only" support:
1. infinite intervals are not representable in mid-rad, and
2. when the midpoint of a (real) interval is exactly in the middle
between two machine numbers, then mid-rad presentation is not unique.
I do not find these arguments sufficiently serious.
You grossly distort the argumentation against a mid-rad datatype.
The main argument against it is that there has been _extremely_ little
past use of mid-rad arithmetic on single intervals. (The only serious
use of mid-rad is for vectorized matrix-vector and matrix-matrix
multiply, and this application doesn't make use of a mid-rad interval
format, but does all computations by means of a midpoint matrix and a
radius matrix. So a standard on midrad intwervals would have no bearing
on this.
I said _mathematical_arguments_ .
I tried to summarize the main _mathematical_arguments_ against mid-rad.
I agree that there has not been too many applications related to mid-rad.
But I do not think that such arguments are of _mathematical_ nature.
Do I distort any _mathematical_ arguments?.