Re: Why (IMO) you should vote Yes to Motion 14.02
Zitat von Nate Hayes <nh@xxxxxxxxxxxxxxxxx>:
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.
Ok, this was casual wording. What I meant is there's never a user
accessible storage in mid-rad. This conversion to and from mid-rad is
entirely internal to the black box of the matrix multiplication. The
user interface consists entirely of intervals stored in inf-sup with
conversion routines to input intervals in mid-rad.
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.
Well, as I already mailed, this is probably nitpicking. I think the
actual wording doesn't prevent you from conforming with
mid-rad---whether it's intended or not. The introduction of
requirements comes entirely from the represented level 2 datum. The
motion says "if you accept to work with a certain level 2 datum don't
approximate it in storage". But we have to sort out the question of
supported formats to have a solid wording of course.
Cheers,
Christian