Re: midrad representation
Yes, Arnold,
there should be a document "specifying at least one reasonable version
of what is the proposed alternative".
I am thinking over producing such a document, possibly a position paper.
I think that operations can be specified for narrow intervals.
My wish is that the document comprises both midpoint-radius form and
complete IA both in sup-inf and mid-rad form.
I shall be happy if somebody else wishes to join me in writing the
document. May be two documents should be compiled: one on
mid-rad form (within "classical interval arithmetic") and another on
complete (Kaucher/directed/modal...) IA.
Due to my limited experience in writing such documents, I shall be
more happy if someone with such an experience takes the leadership
role. May be you, Arnold?
Svetoslav
On 26 Feb 2009 at 17:30, Arnold Neumaier wrote:
> Chenyi Hu wrote on 2009-02-10 in ''the "set paradigm" is harmful''
>
> > Yes, as Baker suggested, I would like to make the motion as the follow:
> >
> > An interval can be represented in two ways in the IEEE-1788 standard. One of them is its lower and upper bounds as [inf, sup]. The other is its midpoint and radius as {M, R}. When the rounding error is ignored, the transformation between these two representations are: M = (inf + sup)/2, and R = (sup - inf)/2; and inf = M - R. and sup = M + R. To ensure enclosure property in the [inf, sup] form, transformation from {M, R} form to [inf, sup] form must consider rounding mode properly in implementation.
> >
> > ==============
> >
> > The rationales for this motion have been discussed lately and in Baker's comments.
>
>
> I think it is poor style, potentially causing difficulties, if
> votes on such important basic decisions are done without a
> document specifying at least one reasonable version of what is
> the proposed alternative.
>
> Otherwise, the voters will have to buy a pig in a poke since they
> don't know the effect of their voting yes.
>
> So far, none of the promotors of midrad arithmetic has given a
> definition of what is meant by it.
>
>
> The only widespread practical use is for speed in Intlab's matrix
> computations, but he converts each time from the infsup representation,
> and back after the operation is done. The scalar mode is always
> performed in infsup arithmetic. Since we do not discuss matrix
> operations in the standard, this use has no consequences for the
> standard itself.
>
> Moreover, in the Intlab implementation, the _centered_ midrad arithmetic
> is used, _not_ the version I can see in the publications of Markov,
> and in my book on interval analysis.
>
>
> The Vianna proposal supports conversion to and from midrad
> representation but does not support operations with midrad intervals.
>
>
> Just to caution you of what to expect if you decide otherwise:
>
> With midrad arithmetic allowed as a second representation on equal
> footing with the infsup representation, a lot of extra work is needed
> to make all definitions unambiguous. It will almost double the size
> of the standard, since most issues need a separate formulation
> for midrad and for infsup.
>
>
> Arnold Neumaier