notes from a conference with Jim Thomas and W. Kahan

[David G. Hough on validgh responding to mail forwarded from sun]

> > Kahan's goal is
> > that you ought to be able to declare the expression evaluation paradigm that
> > you want if it matters.  The paradigms would be chosen from a short list
> > that might include some of
> > 
> > 	Traditional Fortran (no gratuitous promotions)
> > 	Traditional C (floats promoted to double)
> > 	Widest available (all promoted to widest hardware precision)
> > 	Widest needed (widest type in expression, described by Corbett)
> > 	Natural (to a particular hardware)
> 
> Sounds to me like a good place for a #pragma. At the last X3J11 
> meeting it was ruled that pragmas can change the semantics of a 
> program

I'm glad this has happened - otherwise everybody would have had to invent
their own "strong pragma" concept.

> so if we could come up with a set of standard pragmas for this 
> would that help?

I would think that would be an appropriate mechanism.

> "What about the library?" You could compile your own code using 
> whatever evaluation scheme you want but what scheme does your library 
> (which comes precompiled) use?

Expression evalution, strictly speaking, has no library implications.
However if you were to extend operator notions to the standard math
library functions then they would become transparent rather than
opaque in some of the expression evaluation schemes.  Offhand I think this
only implies that you have multiple float, double, and long double
versions of math library operators, which you would expect to provide
anyway to support multiple function flavors, e.g. expf, exp, and expl.
The difference would be that an implementation that otherwise might
provide only expl would also have to provide expf and exp to support some
of these other expression evaluation paradigms.