Re: Motion 6
John,
> As lots of people have said, there is nothing to stop a specialist
> interval package (call it SIP), such as an arbitrary precision one,
> using midrad for various algorithms. The arguments in favour are strong.
this applies to infsup too, no?
> Paul, I am still puzzled about what worries you. It seems to be
> something to do with interoperability -- an "interchange format", as
> has begun to be discussed.
assume P1788 would only standardize midrad, and infsup is better
for your favorite application. Wouldn't you be worried?
> Suppose SIP wants midrad as a private interchange format between its
> own components. Fine, that is no concern of P1788.
>
> Suppose SIP is going to be integrated into, say, the Maplematica
> algebra package. So the latter can do improved arbitrary precision
> interval computations, and display VERY narrow intervals as results.
> Suppose you want midrad as an interchange format between SIP and
> Maplematica, which seems appropriate for such a case. I would argue
> that again, it is an issue between SIP and Maplematica.
>
> It seems pure waste of time for P1788 to try standardise that
> situation, because there are lots of details it doesn't know (which
> may be commercial-in-confidence, and which would be different if SIP
> were to interface to another package, say MuthPad).
again, all of the above applies to infsup too.
> Maybe, however, we could standardise a midrad form in the input/
> output section of P1788? For instance, as decimal text strings
> indicating m +- r where m and r are number strings of arbitrary (not
> necessarily the same) length. Arnold Neumaier already has something
> proposed on these lines, I think.
I just wanted to remind the P1788 working group that there are other
applications of interval arithmetic outside 53-bit precision...
Paul Zimmermann