Re: Why (IMO) you should vote Yes to Motion 14.02
Christian Keil wrote:
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.
Well, I think that depends what does "store" mean. For example, clearly
temporary storage is created internally when the inf-sup intervals are
converted to mid-rad. The endpoints of the mid-rad intervals are then
retrieved, with rounding errors, when the final conversion is made back to
inf-sup.
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.
I think this is why it would be helpful, IMO, to make a clear disctinction
between the internal representations which are not necissarily accessible by
users as opposed to the representation provided by the user as input to the
implementation.
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.
I think if you ask the authors of the motion, they will probably disagree
with you about this, i.e., the particular wording is specifically designed
to rule out mid-rad. I see Ian has already posted a good explanation why.
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?
No! Not at all. In fact, I really like John's suggestion that the difference
between an inf-sup and mid-rad interval type is by whether its Level 3
representation can retrieve either the endpoints or the midpoint/radius
exactly.
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?
I would vote YES to motion 14 if some change like this was made.
Nate