Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Standardizing existing practice or not?

Baker,
New techniques and libraries for Interval Artitmatic are or will be developed and written over the next decade, of generation, by the members of this committee or by their students as an ongoing process.
The operations will be carried out on devices that we are surely not aware of yet in bits or Qubits, or on organic problem solvers. Speed of computing the answer to an operation is always brought forward to boost a particular algorithm/method over another. The rate of change of the processing power continues to increase making those arguments relatively less important. As I recall, subject to a better memory, in the floating point math, much, much less than 1% of the computational time was actually spent on actual FP operations, except in one or two concocted cases, while the remainder was just handling the data. I suspect the same will hold for IA. The usefulness of IA is probably not computationally speed driven.
IEEE 754 served the industry well by making sure that users got the SAME answer for a given operation with the same input regardless of the technique, hardware or software used to get the answer. P1788 could strive for a similar success story.
The SAME answer is not necessarily always the most correct answer, which may be arguable, but is more useful. Reproducible results of IA operations, defined independently of specific library, or algorithm, should foster the use of IA. 

My $0.02 on this.

Respectfully,
Bob Davis

R. Baker Kearfott wrote:

That's certainly a valid point of view.  When standardizing
things that don't exist yet, we run more of a risk. There
are examples where this was done, and the standard was
never implemented or not widely used, because it was too
cumbersome and not useful. However,
there are also examples of the standardization process being
left behind, when needed features are implemented years ahead
of the standard, and we end up with a "Tower of Babel."

Baker

Frédéric Goualard wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I vote NO on Motion 8.02 on the following grounds:

Decorations as proposed by Motion 8.02 have the potential to greatly
enhance the usefulness of interval arithmetic libraries. I have no doubt
about that.

On the other hand, I believe that the standardization process should
sanction techniques and practices that stood the test of time. I am not
aware of any interval arithmetic library that already implements such
decorated intervals. What if, once the standard is passed, decorations
are never used because the way they were defined makes them inconvenient
to use? Are we sure that the decorations defined are the only ones of
importance to all users of interval arithmetic? Will the propagation
rules chosen prove sound for all applications of interval arithmetic?

As I understand it, nobody has any experience whatsoever with
programming with decorated intervals. With work, we may be able to
introduce in the standard a carefully chosen set of decorations with
sound propagation rules. Are we sure all of them will be worth the
trouble *in practice*?

Moreover, the whole machinery of decorations adds complexity to the
standard and raises the bar for potential implementors.

Besides, this is not as if introducing and standardizing decorations was
a necessity now: as said previously on the list, interval arithmetic
libraries have already proved their power and usefulness. And they have
done so without decorations being widely available.

More broadly, I am in favor of standardizing only what is already known
to work and to be useful. Let us add powerful additions like decorations
in the next version of the standard, once the first simple one is widely
accepted and implemented.

FG.
- --
Frédéric Goualard                                 LINA - UMR CNRS 6241
Tel.: +33 2 51 12 58 38    Univ. of Nantes - Ecole des Mines de Nantes
Fax.: +33 2 51 12 58 12            2, rue de la Houssinière - BP 92208
http://goualard.frederic.free.fr/               F-44322 NANTES CEDEX 3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLCqTVEJvxJgN8HkgRAnvuAKCDwtR5RTzVl5R+8psC336qISDD8ACdHU/+
V3lf1xdjuwljW6L8ylNOFUg=
=k+KJ
-----END PGP SIGNATURE-----