3 Compile time constants

• Need a warning that whatever expression evaluation modes you have need to be extended to compile time arithmetic
• W.r.t. generic functions: What about traditional Fortran functions which are neither generic nor have known signatures?

4 Optimization level should be orthogonal from translation modes

5 Want to let programmers write generic programs

You might want to write something that can be run and rerun in higher and higher precision. The programmer has to choose those parameters that depend on some known precision and those which should be defined implicitly.

Convergence criteria may complicate maters. E.g., if you need to converge until the error is less than some constant. The problem is that people often don't know when they should have something that depends on some absolute or something that depends on the precision.

This can be as much a programming style issue as a numeric issue and language issue.

Generic functions turn up naturally in math libraries. Overloaded functions are a bit more restrictive than generic functions. For each data type there is a function and algorithm.

• Examples: Root finding, numerical integration, numerical differentiation , ODE solving

Many of the issues that come up in the discussion of "generic" programming arise because float and double are primitive types that aren't related to one another in some deeper typing sense. In Java float and double are primitive types where a float will be widened to a double automatically at a method call site. However, if you want to capture that information about widening in a language like Java for Kahan's elliptic integral example, you need a number of overloaded methods:

• double integrate(double, double)
• double integrate(double, float)
• double integrate(float, double)
• double integrate(float, float)

Even if the implementation of most of these methods is trivial, like delegating to another method, the API is still cluttered with these marginal methods and the number of methods needed grows exponentially with the number of arguments. Method overloading in Java allows the same name to refer to different (but hopefully related) operations.

In contrast, it would be feasible to construct a system where float, double, and precisions from the tower were just special kinds of "FloatingPointNumbers" so one would write a single method

FloatingPointNumber integrate(FloatingPointNumber, FloatingPointNumber)

and the implementation may test if the arguments were actually float or double. Likewise, the float array versus double array issue comes from relying on an implementation artifact for performance rather than relying on a more abstract interface. That is, from a programming interface perspective arrays are just a map from a set of contiguous integers to some other kind of value, say double floating-point numbers. If that were the only aspect of arrays being relied on the "conversion" of a float array to a double array would be very easy with an adapter object that would convert an element perhaps only when it was accessed.

Of course the extra levels of indirection in such a hypothetical programming environment are inimical to easily getting good performance for operations close to the metal. For 754R, I'd recommend trying to state more abstract desired capabilities of the programming environment.

Could be approached with templates which expand to include the actual types required. This is similar to the tower approach except that an instance of the template will define one base type. Should have some mechanism for double_of and extended_of that basic type. If you want to know if there is a type you could ask is_there(double_of(type)). Probably really want to know if it is native: is_fast(double_of(type)). Would like to be able to take something written for variable precision could be specialized to double, for example. (Would be nice to talk to the LAPack people: they have experience with Fortran and C, for each precision for real and complex.) Some inputs may be special: integer or narrower type for some parameter.

It is important to know what we want to abstract over.

5.1 Issues

• C doesn't allow function overloading
• C99 has some support but it isn't tightly integrated into the language
• Fortran 90 allows overloading. In fortran the convention has been to append a prefix.
• Arrays as inputs create a problem
  • Would want the elements converted on the fly
  • But what if you pass the small array to another routine
  • Could pass a datastructure which maps integers to floating point numbers

Would like to say something to the language community to attract their support for allowing programmers to write programs which are numerically generic.

Would like to have predicates at compile time to make the needed inquiries to select the appropriate algorithm.

5.2 Widest need expression evaluation

(Can be postponed to variable precision, don't want to talk about it in general)

• • • Requires that it scans its generic subprograms and pass this need out
    • This is more demanding than is typical
    • Much more complicated if types aren't known until runtime

6 Difficult to deal with languages which don't allow declaring types

7 Calculators and expression evaluation intended for human eyes should use decimal types.

Actually, most interactive floating-point calculations should be done in decimal.

8 Assignments

9 Meaning of exceptions and flags

<Hide>