Folks,
Let me try to shed some further light on this:
My general impression is that there is confusion here between "internal"
formats and "interchange" formats. Since P1788 hasn't really developed any
standard terminology for this yet, please consider my following comments as
a "work in progress" as I try to (hopefully) find and/or get some
clarification.
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.
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.
In my own opinion, I think it would be very helpful for motions 14 and
16 to
be re-written and to introduce distinctions between "internal" and
"interchange" formats. For example:
An "interchange" format would be some standardize format -- possibly with
standardized Level 3 and Level 4 representations and bit-strings. There may
be different standardized types of interchange formats, namely inf-sup,
mid-rad, and mid-rad1-rad2. For exmaple, in this line of thinking I really
like a comment made a while ago by John Pryce that seems to have been given
little attention:
On 04 May, 2010, John Pryce wrote:
Here's something different but related. The current description of
inf-sup
& mid-rad in our Definitions, e.g.
"2.2.17. mid-rad. Describes a representation of an interval based on its
midpoint and radius."
is pretty vague. I wonder if we should change it on these lines:
- Introduce the term "interval type", suitably defined, to supplement or
even replace interval format" (definition also a bit vague at present).
- Define an interval type to be an inf-sup or mid-rad type depending on
its level 3 representation:
An inf-sup interval type is one whose level 3 representation by
floating-point numbers lets the lower and upper bound of each
nonempty interval of that type be retrieved exactly.
and
A mid-rad interval type is one whose level 3 representation by
floating-point numbers lets the midpoint and radius of each
nonempty [add "bounded" here?] interval of that type be
retrieved exactly.
On the other hand, an "internal" format would be some format used
internally
by a vendor to actually implement the interval arithmetic operations. The
purpose of interchange format is therefore to provide an interface between
the end-user and the internal implementation provided by a vendor.
This internal format could be virtually anything, e.g., an inf-sup pair of
IEEE 754 numbers, some multi-precision or proprietary long accumulator
format, mid-rad, etc. So long as all conversions to and from the internal
format preserve inclusion isotonicity, it shouldn't really matter.
Such a framework I think would be much more flexible and no less accurate.
For example, to any vendor who feels that "exactness" is so important, they
can make sure their internal format is the same as the interchange format.
This way, no rounding errors occur when converting to and from internal
formats. But for other vendors that do not care about this, and who instead
are concerned about other priorities (such as speed or memory bandwith),
these users who would otherwise be supporters and adopters of our 1788
standard won't be left standing out in the cold. I think Intlab is a good
case-study in this regard.
Also, in one closing remark I don't agree with George and John that such a
framework will result in chaos. The reason is simple: unlike intervals,
IEEE
754 and floating-point never was able to employ the simple concept of
inclusion isotonicty.
Nate
----- Original Message ----- From: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>
To: "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Sent: Friday, June 25, 2010 3:40 PM
Subject: Why (IMO) you should vote Yes to Motion 14.02
P1788
Several people voted No to motion 14 for reasons similar to that of Nate
Hayes:
... I think the
standard should otherwise be silent on the internal format used by an
implementation, except that inclusion isotonicity must be preserved.
That is about the needs of those who use representations other than
inf-sup, such as mid-rad. P1788 must meet these needs, but we believe the
above approach is wrong for the following reason.
Consider numbers first. Level 1 is the home of mathematical (extended)
real numbers. Implementing exact arithmetic on this infinite set is a
challenge, so we approximate it by a finite set F, the level 2 real
datums
(of some format). The point about F is
- The datums and their operations have (via the "round" functions) a
precise relation to the numbers and operations of mathematics (level 1).
- And they have a precise representation (level 3) that makes *exactly*
these operations efficient to implement by computer.
It's this "looking both ways" feature that makes level 2 central to the
754 standard.
It should be the same with intervals.
If the present wording of 6.1 is implemented, then every level 2 interval
datum, in every detail, is exactly mirrored by a level 3 object. The
latter determines the datum uniquely: the datum has a *lossless
representation*.
Then also operations on datums are exactly mirrored by level 3 operations
that we write in code; hence by hardware operations on bit-strings at
level 4. This makes that mental construct, a datum, into a physically
real
thing. It seems to me a basic software engineering principle that:
A mental construct becomes real in a program by, *and only by*,
having a lossless representation.
If one loosens in any way the 6.1 requirement that an interval datum be
recoverable *exactly* from its representation, it at once ceases to have
physical reality and becomes a figment of mathematical imagination. (Dan
Zuras made essentially the same point, see below.)
Look at 754, as above. Level 2 floating-point datums are both precise
mental constructs on which humans can do math -- most of them can be
regarded as actual members of the (level 1) extended reals -- and
physically real objects on which computers can do *exactly the same*
math.
And every 754-conforming computer in the world will do that same math.
Thought experiment: Add to 754-2008 this sentence: "An implementation may
represent a decimal64 number by its closest binary64 approximation". At a
stroke the standard's detailed description of decimal64 becomes
pointless.
Binary64 numbers remain physically real, but decimal64 numbers have
become
a figment of the imagination.
Dropping lossless representation would do the same to intervals, with an
effect somewhat like the floating-point chaos that reigned before 754.
Adopting it, by contrast, gives P1788 the solidity that 754 possesses. We
urge you to support the principle
"The representation of Level 2 datums by Level 3 objects should be
lossless"
and vote for the resubmitted motion 14.02.
Regards
John Pryce, George Corliss
========================
On 22 Apr 2010, at 16:30, Dan Zuras Intervals wrote:
Nate Hayes" wrote:
...Why is this important?
Imagine an internal format (such as mid-rad) for which
the extraction of the upper & lower bounds involves an
arithmetic operation that admits the possibility of a
rounding error.
Then it is possible for that format to internally
represent two different intervals, say (m1,r1) & (m2,r2)
such that those two intervals would BOTH extract the
same floating-point numbers as their upper & lower
bounds.
Two such intervals would be both different &
indistinguishable. They would participate in subsequent
operation differently & one would not be able to
understand why.