Bill, P-1788,
A relevant item is Motion 3, "Set of Reals," on
http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
It was subject to extensive debate at the time, and passed in April,
2009 with
48 yes and 5 no. (The primary alternative was with the underlying set
being
the extended reals.)
The discussion on this can be viewed (either by date or
by thread) at
http://grouper.ieee.org/groups/1788/email/
Regarding having a strong standard or a weak standard, I suppose there
are advantages
to either. I do point out, however, that innovators do not
necessarily need to
comply with the standard. According to what I have seen, sometimes
such innovators
prevail and the standard goes by the wayside, sometimes the standard
prevails, and
sometimes both technologies co-exist, with continued problems due to
no de-facto standard.
Baker
On 8/29/2011 2:09 PM, G. William (Bill) Walster wrote:
That's correct, George.
I see no fundamental difference between interval width and speed. No
speed requirement is contained in any computing standard of which I
am aware. Faster is better. For us, narrow *and* fast are both
better, provided containment is not
violated. So, both speed and width can be viewed as interval quality
of implementation features, not requirements. Either unnecessarily
slow or wide results will have limited utility value. There is no
danger either will get used, at least
not for long.
In most of the P1788 discussion I have seen (and I have not seen it
all), there appears to be an implicit assumption that the underlying
mathematical foundation is standard real analysis. If P1788 requires
implementations to use this
foundation, it will preclude any implementation based on other
foundations that produce narrower containment-safe interval results.
The set-theoretic nature of intervals is consistent with possible
alternative foundations. If it is desired
for P1788 to be only for intervals based on standard real analysis,
it might be good to make this explicit rather than leaving it as an
unintended consequence of an assumed mathematical foundation.
Leaving containment as the one and only requirement leaves open the
possibility of alternative containment-safe interval formulations and
implementations that produce narrower width results and even do so
faster. A standard that precludes
alternatives might hinder their discovery because few if any
researchers will be motivated to look for an alternative that
violates a real-based standard.
What still remains to be done in a containment-only standard is to
define the smallest set of values that must be contained. Otherwise
containment violations cannot be proved to exist if and when they
occur. With globally optimizing
compilers, it must be possible to define containment sets at much
higher molecular levels than binary operations, or even arbitrarily
complicated single expressions or functions defined therefrom. So,
there remains much useful work to do.
Defining these high-level containment sets will expose the extent to
which width remains to be reduced.
Cheers,
Bill
On 8/26/11 3:34 AM, Corliss, George wrote:
Dear Prof. Kulisch,
In your paper, you state
"I would fully agree with the motion if the text would say about the
following:
"The number 1 requirement of the standard should be arithmetic
support for comput-
ing close bounds of the set of values of any arithmetic expression
or function defined
therefrom for a given interval of the domain of definition of the
expression or function."
As I understand the intent of Motion 28.01, Bill intends that any
measure of tightness is explicitly NOT required.
George
On Aug 26, 2011, at 2:44 AM, Ulrich Kulisch wrote:
Please see the attachment.
Ulrich
--
Karlsruher Institut für Technologie (KIT)
Institut für Angewandte und Numerische Mathematik (IANM2)
D-76128 Karlsruhe, Germany
Prof. Ulrich Kulisch
Telefon: +49 721 608-42680
Fax: +49 721 608-46679
E-Mail: ulrich.kulisch@xxxxxxx
www.kit.edu
www.math.kit.edu/ianm2/~kulisch/
KIT - Universität des Landes Baden-Württemberg und nationales
Großforschungszentrum in der Helmholtz-Gemeinschaft
<motion28.01.pdf>
George Corliss
George.Corliss@xxxxxxxxxxxxx