Re: Motion 6
Paul, and other people in this thread
On 17 Sep 2009, at 08:26, Paul Zimmermann wrote:
I agree that in fixed (say double) precision, midrad might not be
superior.
But in arbitrary precision, you get a speedup >1 by using different
precisions
for 'mid' and 'rad'. Thus excluding midrad from P1788 might exclude
de facto
efficient applications using arbitrary precision arithmetic.
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.
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.
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).
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.
John Pryce