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



Siegfried,


On Jun 28, 2010, at 4:53 AM, Siegfried M. Rump wrote:

> Just to note: INTLAB is completely NON-commercial,
> free for acadamic use.
Which we VERY MUCH appreciate.

George
> 
> 
> -- 
> =====================================================
> Prof. Dr. Siegfried M. Rump
> Institute for Reliable Computing
> Hamburg University of Technology
> Schwarzenbergstr. 95
> 21071 Hamburg
> Germany
> phone  +49 40 42878 3027
> fax    +49 40 42878 2489
> http://www.ti3.tu-harburg.de
> 
> and
> 
> Visiting Professor at Waseda University
> Faculty of Science and Engineering
> Shinjuku Lambdax Bldg. 902
> 2-4-12 Okubo, Shinjuku-ku
> Tokyo 169-0072
> Japan
> phone/fax in Japan  +81 3 5286 3414
> ----- Original Message ----- From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>; "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>; "John Pryce" <j.d.pryce@xxxxxxxxxxxx>
> Sent: Sunday, June 27, 2010 10:28 PM
> Subject: 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
> 

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