Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Why (IMO) you should vote Yes to Motion 14.02



Friends,

I often argue that we Keep It Simple.  I value commercial endeavors (INTLAB, Nate's work, and others) VERY highly; they have more to do with eventual acceptance of intervals than any number of academic papers.

My extrapolation of Nate's argument below sounds just a little bit like Bill Walster's, "Containment is REQUIRED; all else are quality of implementation issues."  Or simply, "Thou shalt not lie."

A standard requiring (almost) only containment would allow InfSup and MidRad, its exception-handling could be quite simple (but not trivial), and there probably would be (shudder) NO common underlying levels or theory.

Would that be any "standard" at all?

George Corliss

On Jun 26, 2010, at 11:48 AM, Nate Hayes wrote:

> 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.
>> 

Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg