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