Bill,
thank you for your contribution and your opinion
about the timeliness of developing a standard for
interval arithmetic.
May I remind you this working group was of a different
opinion and that's why we decided to start this work.
Please refer to the first mails in this mailing list to get
the arguments that led us to this decision. IEEE
rules insist on referring and considering to previous
mails and discussions,, in order to avoid waste of time
spent on the same topic again and again.
Of course, we welcome any constructive opinion you could
contribute in the direction of building this standard.
Nathalie Revol
On Jun 9, 2011, at 5:56 PM, G. William (Bill) Walster wrote:
I believe Arnold is correct that what we require is "operations that take a list of reals and return a (preferably the tightest) representable interval enclosing the result of an operation with them."
However, this raises the even more fundamental question of what *IS* the result of any given computation, not just basic arithmetic operations? Until this question is answered for all cases of interest, I believe it is premature to even consider developing a standard.
Once this question *is* answered, then the only requirement for any implementation is to *enclose the final result* of any given computation. The syntax and semantics of doing so with a given algorithm in any given language can then be addressed, which, along with returned interval width and speed, are simply quality of implementation issues.
The beauty (to me) of such a system is that it leaves totally open just how hardware, language, software, and algorithm developers might choose to increase their quality of implementation, while always enclosing *the* value of the final results of the computation defined by any given code. We do not want a standard that stifles creativity.
Bill Walster
On 6/9/11 4:15 AM, Arnold Neumaier wrote:
Dan Zuras Intervals wrote:
Folks,
The motion is now,& I quote:
The Motion: Every IEEE 1788 compliant system SHALL provide
the four basic arithmetic operations addition, subtraction,
multiplication, and division with rounding downwards and
upwards. Type conversions with directed roundings SHALL
also be provided.
From our point of view (constraint programming and use in global optimization), we often need both rounding directions for the same operations.
Thus it would be more useful to have operations that take a list of
reals and return a (preferably the tightest) representable interval
enclosing the result of an operation with them. Addition and inner
product of arbitrarily many inputs, subtraction, division with two
arguments, and sqrt with one argument.
This fully substitutes for directed rounding (probably at virtually
no extra cost if done in hardware).
Arnold Neumaier
------------------------------------------------------------------------------------------------------------
Nathalie Revol INRIA Grenoble - Rhone Alpes
LIP - projet Arenaire tel: (33) 4 72 72 85 83
Ecole Normale Superieure de Lyon fax: (33) 4 72 72 80 80
69364 Lyon Cedex 07, France Nathalie.Revol@xxxxxxxxxxx
http://perso.ens-lyon.fr/nathalie.revol/
------------------------------------------------------------------------------------------------------------