Re: Motion 6

[Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>]

Vincent Lefevre wrote:
> On 2009-09-16 16:52:38 +0200, Arnold Neumaier wrote:
> > I'd prefer a motion to exclude midrad from consideration.
> > We have more than enough to do for infsup, and most considerations
> > for midrad are completely different than those for infsup, so that
> > virtually everything done for infsup would need to be reconsidered
> > carefully.
> > As a result, the work load would nearly double.
>
> I don't think so. The common part could be considered, and everything
> else specific to midrad could be left to the implementation.
>
> The relation between (future) language support and P1788 is not clear
> yet, and I fear that if midrad is excluded from P1788, it will be more
> difficult to have it recognized at some levels.
>
> > Nobody in practice uses midrad as a basic representation,
> > except for input/output, where only the conversion behavior
> > needs to be specified, but not the arithmetic.
>
> Perhaps currently. But IMHO midrad would be useful in multiple
> precision, where the error can be in much smaller precision.

In multiple precision, the natural representation is some variant
of Nickel's triplex format, e.g., multiple precision main value
plus float error interval. See Section 1.6 of the Vienna proposal.

But I don't think the 1788 standard should specify requirements
for multiple precision intervals; it should only enable their
efficient implementation using ordinary intervals.


Arnold Neumaier