%-*- mode:latex -*-
\documentstyle[12pt]{article}
\textwidth 6.5 truein
\oddsidemargin 0.0 truein
\evensidemargin 0.0 truein
\topmargin -0.75 truein
\textheight 9.0in

\title{Other languages, C9X: FP98 Course}
\author{Richard Fateman\\
Computer Science Division, EECS Dep't\\
University of California at Berkeley}
%date will be placed here automatically
\begin{document}
\maketitle
\begin{abstract}
This section consists of draft notes on C9X, Modula-3, SANE,
and other
contemporary language standardization efforts and their
access to floating-point facilities (modes, traps).
\end{abstract}
\section{Prerequisites}

We assume that the audience is familiar
with the IEEE 754 standard for binary floating-point arithmetic,
and has just heard 45 minutes from J. Darcy on Borneo, a
variation on Java.

\section{What has to be standardized?}

In these sections we give some examples from C9X, but also
from Modula-3.

{\section{Minutiae: ToMAHto  or ToMAYto?}

There are piles of what would seem to be trivial
issues that boil down to agreement on
the names to be used for various flags, traps and actions.
Since the bit patterns for registers are not legislated,
mode mapping varies from platform to platform, and there
must be names for the bit positions.

C9X provides a type {\tt fenv\_t} with the 
intent to represent the entire floating-point environment.


C9X gives following names (as macros) for flags in the
floating-point environment:
\begin{verbatim}
FE_DIVBYZERO	FE_INEXACT	FE_INVALID
FE_OVERFLOW	FE_UNDERFLOW
  with
FE_ALL_EXCEPT representing the bitwise OR of the above.
\end{verbatim}

Additionally,
\begin{verbatim}
FE_DOWNWARD	FE_TONEAREST	FE_TOWARDZERO	FE_UPWARD
\end{verbatim}
are macros defined iff the implementation supports testing (get)
and setting rounding direction by means of 
{\tt fegetround} and {\tt fesetround}
functions.

If the programmer intends to access {\tt fenv}
in a non-default way, then the program must
include 
\begin{verbatim}
#include <fenv.h>
#pragma STDC FENV_ACCESS  on-off-switch  
 //pragma lasts until end of ``translation unit''
\end{verbatim}

note:failure to set pragma and then 
setting flags leads to an ``undefined program.''

\begin{verbatim}
feset_except, fetest_except, feraise_except
\end{verbatim}
functions are provided, though the
prospect of using them to raise signals and have the C
language deal with them is implementation dependent, and
could apparently be ignored without affecting
the validity of the implementation. (C9X section 7.11)

If the implementation so chooses, there are possibilities
for {\tt SIG\_DFL}  (default) handling or {\tt SIG\_IGN}  (ignore)
handling, or a user-inserted function with limited access
to variables or serious functions.  It appears to be
possible to return to a place where an exception was
raised by a {\tt RAISE} function.

\begin{verbatim}
//example in C9X
#pragma STDC FENV_ACCESS ON
int save_round;
int setround_ok;
save_round=fegetround();
setround_ok=fesetround(FE_UPWARD);
assert(setround_ok); //bomb if rounding mode inaccessible
/*compute something in here */
fesetround(save_round);

/*etc*
\end{verbatim}

{\bf Incidentally, the Modula-3 language words are all different...}
}

\section{Extending well-known functions}
{There are large numbers of questions that have
to be resolved in a fixed way, subject to debate on
what is the most useful computational result. 

Natural extensions don't always exist: compromises must be
made. Their consequences must be traced through the design so as to
formulate as coherent a system as possible.

Example.  What is the max of (0,NaN)? 

Sample desirable axioms:
\begin{itemize}
\item  {\tt max(x,y)} must be the same as {\tt max(y,x)}.
\item  These comparisons return FALSE:
\begin{verbatim}
 max(x,y) < y
 max(x,y) < x
\end{verbatim}
\end{itemize}
This means that {\tt max(NaN,x)} could be either NaN or x, a non-NaN.
Tough choice.

How best to identify
values of complex functions on branch cuts?


(Need clear definitions for elementary function defaults).
There are uses for signed zero allowing us to distinguish,
for example,  x+0i  from x-0i. (WK paper on
Branch Cuts for Complex Elem. Funs, 1987)
}

\section{Descriptive vs Prescriptive}
There are too many loose ends for implementation dependencies to make
C9X standard {\em per se} a useful guide to careful implementation of
float-based algorithms.  The acceptability of a valid C9X
implementation to do anything {\em or nothing} at so many 
decision points is probably
viewed by the writers as a way of not backing the compiler/computer into a
corner by prescribing too much. 

Unfortunately, it backs the programmer
into the middle of some under-specified territory without an adequate
map.  It seems that this language standard
leaves important details to the vagaries of the implementation.
And worse that it is considered acceptable in the ``language
standards'' community to work this way.


\section{Designing the next language}
It is not easy to design a programming language:
constraints (size, speed, environment, portability),
trade-offs (expressiveness, generality, efficiency).

We should be standing on the shoulders, not
the feet of those who worked on these problems.


Where to look for help (shoulders, not feet).

\subsection{Modula-3}

Modula-3 is a descendent of Algol-60 via Pascal and Modula-1,2,
with a free implementation (for many platforms) courtesy of DEC
Systems Research Center.  More details can be found from.
\begin{verbatim} 
http://www.research.digital.com/SRC/modula-3/html/home.html
\end{verbatim}
While there are implementations of the language
for a number of platforms, they are
not necessarily complete with respect to floating-point 
details.
(e.g. a glance at the SPARC
code shows that rounding modes are set globally, not
per thread).

\subsection{Borneo}

\begin{verbatim} 
  http://http.cs.berkeley.edu/~darcy/Borneo/
\end{verbatim}

There is no implementation for Borneo, a variant of Java developed by
J. Darcy and W. Kahan at Berkeley.  Since the existence of any
variants of Java are anathema to the purveyors of Pure Java, it
becomes important for the propagation of such ideas in the language to
influence the Java purveyors. This raises political and financial
concerns. (History of Java, Borneo?)

The Borneo definition document includes
innumerable other ``trivial'' items that must be specified
for a language:
(example: How precise are constants?) 

Recommended reading for a design team.

\subsection{SANE}
SANE is Standard Apple Numeric Environment, built for
the Motorola 680x0. The current Apple processor
architecture (Power PC) is different, requires recompilation
and may also require some attention to programs.

Some differences:

PPC has double-double but not double-extended.

Whereas SANE may avoid intermediate overflows (by always using
wide intermediates) PPCN does not necessarily do so.

Differences in exception handling, round-to-precision,
precision of the subroutine library (generally PPCN
has lower precision!)

\begin{verbatim} 
http://developer.apple.com/techpubs/mac/PPCNumerics/PPCNumerics.166.html
\end{verbatim}

The Rhapsody operating system (coming up sometime) is, under the
covers, a UNIX system supporting C, Objective-C, Java.  FP support
seems to be whatever is in C/UNIX (or Java).
/end{document}

\section{Some philosophy}

There is a pervasive and generally useful notion that is popular
among application programmers that if you run a complicated
floating-point calculation and are unsure if the answer is
correct, a simple check may be available: If a higher precision
version of the program can be run, try it.  If you get the
same answer in single as well as double, then it is probably
correct.  Or double and quad, etc.  While this can be
merely signal agreement to the wrong answer, why are we
not happy with it? 

(Followed to its logical conclusion as has been done by
some hardware designers, one finds many niceties
eliminated.  Who cares if the results are entirely accurate; if
it matters, the computation will be re-done to higher precision
and in wider exponent range arithmetic.

Sloppy division, rounding incorrectly, cavalier treatment
of underflow, imprecise interrupts can all be excused in the
name of speed.)


Why should we care? It depends on who is meant by
``we''. 

An engineer needing a one-off solution of a problem
that is in the middle of a very well-conditioned
problem might not care, {\em except that he might be wrong and
his problem is on some border (or his program is unstable)}.

We as suppliers of supposed quality hardware and software
should care [ref:WK's {\em Matlab's Loss is Nobody's Gain},  draft]

When one is constructing software for re-use by others (libraries,
interactive engineering packages etc), then one cannot put
a cost on inaccuracy.

In particular, the numerical software ``engineer'' cannot generally
judge for users of some library
\begin{itemize}
\item Where less accuracy is acceptable (context unknown);

\item How (in)accuracy might be magnified by subsequent use;

\item How inaccuracy might be associated with risk.
\end{itemize}

Purveyors of software and hardware must protect the (relatively
speaking) naive users from excessively inaccurate computation.

``Kahan's Law on Precision'' An increase of K significant bits
in an intermediate result's accuracy decreases by 2\^~(-K) the
incidence of numerical embarrassment attributable to the later use
of that result.



\end{document}







