Re: Why (IMO) you should vote Yes to Motion 14.02
Christian Keil wrote:
CK> ... If I read it correctly,
CK> Motion 14 does not rule out mid-rad intervals. The only thing it says
CK> (leaving the title of 6.1 aside for the moment) is that the bounds must
CK> be retrieved exactly, but it doesn't specify the nature of the level 2
CK> datum. Additionally it mentions multi-precision representation of
CK> intervals by the triple (x_hat, delta_l, delta_u) to be conforming.
CK> Therefor a mid-rad representation seems to be conforming to these
CK> requirements. ...
Pick an interval in which the least significant bit of the lower bound is 0, the least significant bit of the upper bound is 1, and all other bits of the lower and upper bounds are identical.
With a mid-rad representation, the mean should be halfway between those, and the radius should be a normalized form of the same exponent but a fraction of all 0 bits then a 1 bit to the right of the least significant.
Those mean and radius are not always representable. An obvious group is when the bounds are subnormals and the exponent can't be adjusted.
So requiring that the lower and upper bounds always be retrieved exactly seems to exclude mid-rad, unless the mid-rad uses higher precision.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Christian Keil ---06/28/2010 03:31:14 PM---As already noted and supported by the Intlab source: Am Sat, 26 Jun 2010 11:48:13 -0500
From: |
Christian Keil <c.keil@xxxxxxxxxxxxx> |
To: |
Ian McIntosh/Toronto/IBM@IBMCA |
Date: |
06/28/2010 03:31 PM |
Subject: |
Re: Why (IMO) you should vote Yes to Motion 14.02 |
As already noted and supported by the Intlab source:
Am Sat, 26 Jun 2010 11:48:13 -0500
schrieb "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>:
> I think we are all agreed that making Intlab an exemplary
> non-conforming implementation of the future 1788 standard isn't one
> of our goals, as this would really be shooting ourselves in the foot.
> The interesting thing about Intlab, however, is it performs some of
> its internal calculations in mid-rad format, e.g.:
>
> On 11 Apr 2010, Marco Nehmeier wrote:
> > In our opinion Motion 16 does not say any word on internal formats.
> >
> > It is possible to implement a supporting type in any thinkable
> > internal representation. For example the implementation in Intlab
> > uses a internal mid-rad representation for some operations but the
> > interface is still inf-sup (see mail from Arnold Neumaier
> > 10.05.2010 15:26)
>
> Now, since the mid-rad format used by Intlab does not allow the
> endpoints of any interval to be retreived exactly, by Motion 14
> standards I don't see that it will be conforming.
I support John in his view here. The intervals are _never_ stored in
mid-rad format. For certain operations, as multiplication of matrices,
they are converted to mid-rad, the matrix product is computed, and the
entries are converted to inf-sup again and stored. Therefor the
conversion is so to say internal to the operation. The accuracy might
be an issue depending on
the standardized accuracy requirements, but Intlab IMHO doesn't
violate the current Motion which isn't on operations but on
representation: any user accessible interval is stored inf-sup.
> Furthermore:
>
> On 11 Apr 2010, Dan Zuras wrote:
> > While I'm not quite sure what you mean by 'internal format',
> > neither that nor 'interchange format' are used in this motion or
> > intended.
> >
> > Neither supported formats nor available formats need be interchange
> > formats.
> >
> > Nor is it intended that arithmetic in an inf-sup format be able to
> > be 'simulated' by a mid-rad format or vice versa, internally or
> > otherwise.
>
> Particularly by the interpretation of the last sentence in Dan's
> statement above, I have the impression Intlab will also not be
> conforming even by Motion 16 standards. This is because Intlab
> clearly "simulates" in some cases an inf-sup format by performing
> internal calculations in mid-rad format.
Let's try not to mix motions 14 and 16 when discussing the merits or
flaws of one of them. I understand that you see the same flaws in both,
so I'm trying to sort out if these really conflict with the ideas
expressed (especially) by John and Dan.
First of all a note to the proposed wording. If I read it correctly,
Motion 14 does not rule out mid-rad intervals. The only thing it says
(leaving the title of 6.1 aside for the moment) is that the bounds must
be retrieved exactly, but it doesn't specify the nature of the level 2
datum. Additionally it mentions multi-precision representation of
intervals by the triple (x_hat, delta_l, delta_u) to be conforming.
Therefor a mid-rad representation seems to be conforming to these
requirements. It might not be the intention by the author but I don't
see it excluded. I'm not quite sure on the implications of 6.2 in this
regard---but I think it should be compatible.
To me it seems the concern of John and Dan is to avoid a loss in
accuracy between levels 2 and 3, the interval datums and their
representation on the machine. I think this concern is not about
interchange or internal format, not about I/O, but about the
construction of the objects that we are dealing with, is that right,
John, Dan?
Nate, do you disagree to this mapping between levels 2 and 3? Or is
your argument also addressed, if the referenced level 2 datums could be
mid-rad intervals, which could be represented without loss with a
corresponding pair of floating point numbers? In this case with a
little rewording (remove 'by lower/upper bounds' from title of 6.1, if
we have mid-rad in the standard we should add a representation note;
remember that this is not about setting standard text in stone, it's
about starting to write on the standard) Motion 14 could be agreed upon
and the argument would be about Motion 16?
Cheers,
Christian