Friends,
A standard will be successful in the long run if it is adopted and embraced by commercial enterprises. One purpose of the standard is to increase the probability of systems from various manufacturers working in the same way, at least as far as applications developers need to know. Our common goal is to see people practicing reliable computing. That is much more likely to happen if at least come vendors see it as a way to make money. Hence, any standard is as much a business document as an academic one.
An interval standard that spells out the core of current accepted practice MIGHT be successful by my adoption metric.
An interval standard of perfect academic beauty, completeness, and including every variant is GUARANTEED to fail by that metric.
No one is saying that a [inf, sup] standard prevents anyone from doing mid-rad or Taylor models any more than 754 prevents anyone from doing variable precision.
KEEP IT SIMPLE.
Dr. George F. Corliss
Electrical& Computer Engineering
Haggerty Engineering #296
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee WI 53201-1881
George.Corliss@xxxxxxxxxxxxx
414-288-6599; -288-4400 (GasDay); -288-5579 (Fax)
Www.eng.mu.edu/corlissg
On 2/10/09 8:44 AM, "Dan Zuras Intervals"<intervals08@xxxxxxxxxxxxxx> wrote:
Baker& co,
I realize you are doing part of your due diligence as chairman
to suggest this motion but I must say that I would resist such
a motion.
I have not commented yet because far better qualified people
have been making the case against this. But the simple fact
is that midpoint-radius representations are not equivalent to
or interchangable with inf-sup representations.
There is no problem with specifying conversions to& from the
midpoint-radius representation but to have some implementations
use it for calculations& others use inf-sup representations
would be inconsistent with our overall goal of assured
computation.
(If it comes to it I can make the case for that claim in a
later note.)
I believe that what Svetoslav wants is a laudable goal but
involves different principles than we are trying to lay down
here.
While he may not believe it at the moment, I believe that
Svetoslav will be able to do useful work with intervals as
we will end up defining them.
Let's let that process play out& see...
Dan
Date: Tue, 10 Feb 2009 07:43:01 -0600
From: Ralph Baker Kearfott<rbk@xxxxxxxxxxxxx>
CC: stds-1788@xxxxxxxxxxxxxxxxx
Subject: Re: the "set paradigm" is harmful
Svetoslav et al,
I see several possibilities of accommodating midpoint-radius
representations in the standard. One might be to simply
specify two representations for intervals, and specify
conversion between the two. (That might be the simplest way.)
Does anyone care to make a formal motion to that effect?
If such a motion passes, we can then work out details.
There is another representation of intervals in use to avoid
having to change the rounding mode: [-inf,sup]. However, we
may be able to accommodate that representation within the [inf,sup]
representation by "as if" wording.
Baker
P.S. I'm not sure in exactly what places, if any, the issue of accommodating
midpoint-radius impacts the two motions currently being
formally processed. (P1788/M0001.01_StandardizedNotation and
P1788/M0002.01_ProcessStructure) The first deals with the
notation to be used in the standards document and the second deals
with the structure of the standards document (and not its actual
content). If there is anything within these motions that
impacts midpoint-radius, please be VERY specific about where.