Some highlights from NCEG Meeting #3

[David Hough]

I report some of things that struck me at the third NCEG meeting in New York,
7-8 March 1990.  From Sun engineering you can format this report with
tbl ~dgh/memo/nceg3.highlights | troff -ms

     The following highlights are things that struck me for one reason or
another during NCEG3 as relevant to some issues I've raised in this mailing
list before.  I took in only a small fraction of all that was going on, how-
ever.  Some of the other proposals that were presented include

*    Variable-Size Arrays (90-009) Ritchie.

*    Compound Literals (90-010) Ritchie.

*    Pixel C (90-013) Vick.

*    IBM Proposal for Vector Extensions to C Language (90-014) Sorkin, Dono-
     van.

*    Vector Extension to C (90-016) Pennello.

     Other talks included progress reports on

*    Pragmas/Macros/Namespace

*    Aliasing

*    Complex arithmetic

*    Array syntax

     If you are interested in any of these you might want to get on the
(paper) mailing list; contact Rex Jaeschke, the convener
(uunet.uu.net!aussie!rex).  I think most topics are heading toward satisfac-
tory solutions; I'll consider the final NCEG report satisfactory if a full
implementation in otherwise ANSI C removes all advantages to writing new code
in Fortran, and at least IBM, DEC, and Cray move toward full NCEG implementa-
tions on all their computational platforms; that should be enough to pull
everybody else along.

Superstandard/substandard IEEE NCEG

     Out of about 26 present, 12 indicated they might vote to include a
fully-developed proposal along the lines I indicated.  A while back I circu-
lated some hints about what superstandard/substandard modes might entail.

     The idea was to produce identical results on all superstandard IEEE sys-
tems.  This requires several things beyond IEEE 754:

*    The superstandard mode has to be the default to be worth doing at all.

*    It has to apply to a lot of programs to be worth doing at all.

*    Identical extended formats, or none.

*    Correctly-rounded elementary transcendental functions and even some
     tricky algebraic ones (hypot and base conversion).

*    Identical expression evaluation, of e. g. x+y+z; rounding errors must
     occur in the same order everywhere; this inhibits some vector and paral-
     lel optimizations.

*    Identical exception detection and trap handling capabilities.  No room
     for differences in underflow definition.

     I thought about scaling back my ambitions as far as NCEG is concerned to
restrict superstandard mode to specifying float and double only, and algebraic
operators and functions only, and applying only until an exception is detected
other than inexact.  This restricts the applicable domain but increases the
ease of implementing superstandard mode.  I expect that such a restricted
superstandard mode would be easy on a 68040, for instance, but I was reminded
that 80387 extended precision rounding mode affects only precision and not
exponent range, so identical results could not be guaranteed after an under-
flow unless all operations stored results to double and reloaded.

     Some aspects of superstandard/substandard mode are inherently compile-
time; others run-time.   Thus the choice would have to be made at compile time
to insure that x + y + z was evaluated superstandardly, while the run-time
software would probably implement base conversion and elementary transcenden-
tal functions according to a flag initialized at load time or crt0 time.

     Perhaps superstandard mode is premature for NCEG.  Some people thought it
should be extended to non-IEEE systems, as well, although I don't see the
point.  DEC, IBM, and Cray could extend their non-IEEE architectures to
specify correctly-rounded elementary transcendental functions, for instance,
with no need for external standardization.

Exception handling

     Out of about 26 present, 12 indicated they might vote to include a
fully-developed proposal along the lines I recently circulated, which call,
for each exception, uniform treatment among hardware and software operators
and functions.  No uniformity among exceptions is proposed.  Implementations
must provide functions which tell which exception handling capabilities they
support, but they don't have to support any except "other".  The price of
allowing an "other" response is a recommendation in the proposal that all
implementations SHOULD offer IEEE-style exception status accumulation and
SIGFPE'ing.

     Like superstandard/substandard, the exception handling mode would have to
be declared at compile time but implemented partially at run time as well.  In
any event the goal is to allow more than one kind of exception handling imple-
mentation while permitting portable applications to inquire to determine
what's in effect in order to respond accordingly.

     I received a written evaluation from Martha Jaffe which in essence sug-
gested my exception proposal was too wishy-washy; I have to agree, but it's a
difficult balancing act to think of some way to encompass something useful AND
a standard C implementation that just does errno.  The only vote in X3J11
against licensing the NCEG activity as a subcommittee was from Doug Gwyn,
motivated by precisely this issue of upward compatibility of errno.

Operators

     I started by outlining a macro which might follow the definition of
sqrt() in math.h:

        #define sqrt(x) \
                ((sizeof(x) == sizeof(double)) ? __sqrtd((double)(x)) : \
                 (sizeof(x) == sizeof(float )) ? __sqrtf((float )(x)) : \
                 (sizeof(x) == sizeof(long double)) ? __sqrtl((long double) (x)) : \
                 bad_sqrt_usage )

This definition would be appropriate on systems in which there were separate
float, double, and long double instruction sets with differing efficiencies.
Most attendees agreed that there would be only one evaluation of x and so this
would be a legal replacement in that respect; further most felt their com-
pilers would optimize this definition away so there would be no conditionals
in the generated code.  Even so there was some agreement that macros of this
sort were not edifying or expedient.

     It occurred to me that the predicate this macro really needed (in place
of two sizeofs) was typesame(x,y), which would return 1 or 0 according to
whether the expressions or type names x and y had the same type.

     Out of about 26 present, 16 indicated they might vote to include a
fully-developed proposal along the lines I indicated.  This was a larger per-
centage than I had expected; I had assumed that adding operators to the
language (new reserved words) would be anathema.  So I will develop these
ideas further.

Expression evaluation

     I didn't have time to present arguments for expression evaluation that
takes into account the types of destinations as well as operands.  This is
another area which may be repugnant to C (and Fortran) traditionalists.

IEEE NCEG

     Jim Thomas' proposal for IEEE NCEG has progressed to an advanced state of
refinement.  There are a number of open issues that I will try to comment on
later.  There is a lot of room for problems between the IEEE NCEG proposal and
any kind of superstandard proposal.

Other

     NCEG agreed that it would not be bound by the six characters/one case
external identifier restriction since it was unlikely to be in force on any
system likely to implement NCEG.

     X3J11 decided earlier in the week that no pragmas were permitted in
strictly conforming ANSI-C programs.

     There are two schools of thought about variable-dimension arrays: these
could be called Fortran-like and Pascal-like.  Fortran-like arrays just change
the interpretation of a random pointer argument according to some other
dynamic dimension variable(s) that can only be evaluated at run time.  This is
very flexible and something like it has already been implemented in GCC.
Pascal-like conformant arrays carry their bounds around with them in descrip-
tors that are passed in lieu of normal pointers.  This is probably a safer and
superior system but it is somewhat different from anything Fortran or C pro-
grammers have been used to so far.  Nobody seems happy about offering both
facilities in one language.

     nextafter(x,y): as defined in IEEE 754/854 is more trouble than it's
worth.  After thinking about how it should work in an extended-precision
expression evaluation environment, I decided it was easier just to define
nextdouble(x) (as well as nextfloat() and nextlongdouble() ) that return the
least machine representable double value > x, unless x is +infinity or quiet
nan, in which case x is returned, or if x is signaling nan, in which case
quiet nan is returned.  The only exception that might be worth considering is
invalid for nan argument.  To go the other way, use -nextdouble(-x).

     Most uses of nextafter(x,y) are in environmental inquiries that require
successors or predecessors to x in a definite direction - either up or down.
The only other cases I can think of would be in nonlinear equation solving
where you might want to perturb one point slightly closer to another, to avoid
a singularity, without having to figure out which direction. Instead the
figuring out which direction occurs in the implementation of nextafter.

     I discovered later that the X3T2 proposal from Payne, Wichmann, et. al.
has pred(x) and succ(x) functions not too different from what I have in mind.

     The most primitive next operations are stepping toward zero and away from
zero, but if these were the defined functions then there would have to be a
pair of them rather than one.

     It occurred to me that on IEEE systems without precise traps, there isn't
much use left for signaling NaNs except for initializing storage; and much of
that value of that would be lost on systems for which initializing storage to
-1's produces quiet NaNs (all Suns, for instance).  The original intent was to
use signaling NaNs for extensions, but that requires the ability to trap,
recompute an answer, and continue, which hasn't been fully and conveniently
implemented so far.  So perhaps signaling NaNs are an idea whose time is pass-
ing, unless presubstitution systems can exploit signaling NaNs well.

     Permitting inf and nan on input/output via an NCEG locale doesn't seem to
be a solution.  You might need NCEG variants of all supported locales.  A
somewhat better idea is to capitalize INFINITY and NAN on output for %E and %G
and use lower case in the more common %e, %f, and %g.  That corresponds to
what %E and %G do to the exponent letter E.

     The most attractive notation for complex data 3.0 + 4.0i is problematic
in situations like x + 3.0 + 4.0i where the order of evaluation might be argu-
able; that might have consequences for IEEE signed zeros and signaling NaNs,
for instance.

     Questions for experts in complex variable theory: Can the logarithmic
singularity log(0) be properly described as a pole?  Is z*log(z) analytic at
0?

     The next NCEG meeting will most likely be September 26-27 in Pleasanton,
CA, near Livermore.

     Rex distributed samples of a very compact reference card for ANSI-C list-
ing all keywords, operators, and include files.

     What you may have known as Spectrum or Precision or HPPA is now to be
known as PA-Risc (or something like that) since HP, deciding to license the
architecture externally, needed a more attractive name for non-HP vendors.

Travel notes

     Airlines:  San Jose is connected to eastern locations via connections in
hub cities like Dallas, Denver, Chicago, St Louis, and Salt Lake.  These con-
nections are usually scheduled for an hour on the ground between flights.
Don't believe it.  It seems to be generally true that connections to/from San
Jose have a 50-50 chance of missing, independent of airline or hub.  Expect it
and plan for it.

     Hotels:  The LaGuardia Marriott staff is so cheerful and friendly that I
had trouble believing I was in New York.  One of the managers was pleased when
I commented on that and admitted that it was something of an intensive ongoing
education and indoctrination process.

     Restaurants:  If you are ever stuck in a hotel in Queens, you can get a
pretty good lunch or dinner for $7 at Nuestra Bolivia in Northern Blvd near
85th or so.  The management speak English and give reliable recommendations if
you ask.

----------------------------REMINDER----------------------------

You receive this message because you are on the mailing list
        ...sun!dgh!numeric-interest
Send messages to that address about floating-point arithmetic,
elementary transcendental function computation, numerical exceptions,
and related C and Fortran issues.

To get yourself off that list or to get somebody else on, send mail to
        ...sun!dgh!numeric-request

Other forums are appropriate for more general discussions:

        na-netana-net.stanford.edu
                moderated mailing list for numerical discussions
                requests to nanetana-net.stanford.edu
        sci.math.num-analysis
                unmoderated USENET newsgroup for numerical discussions