Re: Why (IMO) you should vote Yes to Motion 14.02
> Date: Mon, 28 Jun 2010 21:28:50 +0200
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 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.:
The status of Intlab as conforming or non-concorming is
not an issue for us at this time & should not be part of
this discussion.
But, at the risk of alienating those who we are trying to
get to cooperate, I think that holding up Intlab as 'an
exemplary non-conforming implementation' is EXACTLY the
right thing to do.
We are not in the business of blessing any existing
interval implementation with the IEEE seal of approval.
But that should not prevent us from looking at those
exemplary features of existing implementations & demanding
that conforming implementations are similarly well behaved.
Nor does it prevent us from demanding of even an exemplary
implementation that, "You could be made to conform if only
you added these few new features."
That's enough on that irrelevant point for now.
On to Motion 14.02.
> >
> > 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.
I am not familiar with Intlab. I have never used Intlab.
I do not know how Intlab does its work.
But were it ME & I had to write an interval matrix multiply,
I would leave the realm of intervals altogether. I would
compute (or extract, as the case may be) the midpoints &
store them in floating-point matrices. I would compute (or
extract) the radii & store them more matrices. Then I would
calculate the floating-point product by whatever method I
deem useful as well as the Jacobian & a 3rd result involving
an estimate of the floating-point errors committed in the
product calculation. Then I would extract the midpoints
from the product matrix. I would combine the results of
the Jabobian times the radii & the floating-point error
matrix & extract the resulting radii from that. Then I
would return the resulting interval matrix in the desired
interval form (either mid-rad or inf-sup, it does not
matter).
And all of that would STILL CONFORM to the spirit of a
conforming implementation we are trying to create.
As will, I suspect Intlab.
And all of that is still, of course, ENTIRELY IRRELEVANT
to the text in 6.1 & 6.2 which speaks only of a format
that has an exact surjective mapping (6.1) & a hull
operation (6.2).
The controversy seems to be entirely over the informative
note that gives 2 examples of inf-sup representations, one
of (mid,rad1,rad2) & acknowledges the existence of others.
An informative note is just that, informative. It carries
no weight. It makes no restrictions. It need not even be
RIGHT. It just informs or guides the reader about the uses
or intentions of the rest of the text.
That's all.
>
> > 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.
That was not my intention at all even though there are
serious caveats. And, of course, ...
>
> 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,
... as Christian correctly points out, none of this has
anything to do with motion 14.
> 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
That is correct. However, it may put an undue burden on
a mid-rad format that is trying to 'appear' to the user
as an inf-sup format. Perhaps more than is desired.
> (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
Correct, nothing is specified except by its behavior.
And the only behavior specified is that the bounds
shall be exactly retrieved & that containment shall
be preserved on type conversions.
That's all.
> datum. Additionally it mentions multi-precision representation of
> intervals by the triple (x_hat, delta_l, delta_u) to be conforming.
It mentions this in the informative note. There is
nothing more going on here than that it is the intention
that such a format MAY BE made to conform &, as such,
should not be excluded.
> Therefor a mid-rad representation seems to be conforming to these
Just so, with some caveats.
> 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.
You will have to speak to John about his intentions but
it is certainly not my intention to exclude mid-rad.
>
> 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?
You have it exactly. Yes.
>
> 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
I have been vague about the 'caveats' I have mentioned.
They have to do with the burden that exact extraction
might put on a mid-rad format.
I see in my inbox a note from Ian McIntosh in which he
illustrates the problem eloquently. Let me explain
things in my reply to him.
On to yet another note...
Dan