an opportunity to address ICIAM

[David G. Hough on validgh]

ICIAM is the premier international gathering of applied mathematicians, but...
two days ago I missed
my connections for the third consecutive time on a flight from the east coast
to the west, so I'm convinced commitments to be in Washington DC 3:30-5:30 PM
on Tuesday 9 July and in Kona Hawaii at 7 AM on Thursday 11 July are fundamentally
irreconcilable.  Thus I would like to solicit a volunteer to speak on the topic
outlined below on Tuesday 9 July.  If you are interested let me know.
Your opinions needn't coincide with mine as long as you present the main issues.
I can offer some financial assistance with travel expense if that would help.

The session title is Scientific and Numerical Computing in C.  There will be 
six talks of about twenty minutes each; the others are:

An Overview of the C Standardization Work - X3J11 and NCEG - Vouk
Converting Fortran to C - Feldman
Are Vectorizing C compilers helping the scientific C programmer? - Smith
Programming Massively Parallel Systems in C - Frankel
Coping with Arrays and Pointers - Vouk

For more details about this talk, please contact dghavalidgh.com.
For more details about the rest of this session, please contact voukacscadm.ncsu.edu.
For more details about the rest of ICIAM, contact iciamawharton.upenn.edu.

--------------------------------------------------------------------------------

Here's the abstract I submitted:

With the benefit of an ANSI Standard C programming language and an
ANSI/IEEE Standard for Binary Floating-Point Arithmetic, naive users
might expect that programming environments conforming to both standards
would produce identical numerical results.  More experienced
programmers would be able to "prove" that such results are technically
unfeasible, uneconomical, and undesirable.

What's a realistic expectation?  There are genuine mathematical issues
relating to elementary transcendental functions, performance issues
relating to systems that compute anonymous intermediate results in
extended precision, and philosophical issues relating to
standardization: what should be standardized and when, for
standardization suppresses innovation, both good and bad.  These issues
are aggravated if exception handling is also standardized: what was
cheap and convenient on simple computers may be exceptionally costly on
high-performance systems, and the cost may be payable even by programs
which generate no interesting exceptions.
 
The Numerical C Extensions Group faces such questions among many others
as it seeks to extend ANSI Standard C to a language for mathematical
software that is superior to Fortran-77 in every respect.

--------------------------------------------------------------------------------

Here are some slides I produced for a preliminary version of this talk:

           Mathematical Software in Standard C:
                 Why no Standard Results?


             Standard Floating-Point Arithmetic

             IEEE 754
             IBM 370
             DEC VAX
             Cray



                    ANSI-C, ANSI-Fortran

          not much about arithmetic, or exceptions
          except ANSI-C <math.h>



             Why don't we get standard results?

             same numerical results
             same exceptions

             base conversion
             expression evaluation
             transcendental functions



             Base conversion is relatively easy

             to be correct
                Jerome Coonen's thesis
                David Gay's netlib code
             to be fast
             to be small
             but all three is harder

             print *,x

                Expression evaluation issues

          higher precision expression evaluation
          multiple operations - one rounding error
          parallel processing



          Higher precision expression evaluation

         double evaluation in C
         double evaluation on RS/6000
         extended precision registers: x86 and 68k

         Better accuracy
         Better performance
         Inconsistent storage behavior



                         t(i)=expr
                             ...
                     if (t(i).eq.expr)
                              ...

          Multiple operations - one rounding error

          z = x + (y * z)
          complex multiply
          sqrt(x*x + y*y)


                    Parallel processing

                    do i = 1,n
                    s=s + x(i)*y(i)

                    do i1=1,n1
                    s1=s1 + x(i1)*y(i1)
                    do i2=n1+1,n
                    s2=s2 + x(i2)*y(i2)


                  Transcendental Functions

                  Table-maker's dilemma
                  Large tables
                  Error bounds
                  Multiple algorithms

            What benefit from standard results?

         Network computing
         Debugging hardware problems
         Debugging compilers

         Selectively enable/disable:
         Standard base conversion
         Standard expression evaluation
         Standard transcendental functions

         Compile-time, link-time, run-time options


              What cost for standard results?

              Base conversion:
                 large tables
              Expression evaluation:
                 performance
                 accuracy
              Transcendental functions:
                 performance cost very high