NCEG goals and deliverable

[David Hough]

Some of the people who haven't been actively participating at NCEG meetings
may not be aware of what we're trying to do, how we propose to do it, and why
we're bothering.  I'll give my perspective on that.  Others will no doubt
offer differing views.

The NCEG deliverable is a technical report of proposed extensions to ANSI-C
to address numerical shortcomings of ANSI-C
in which NCEG members are interested.   We agree that extensions SHOULD be
upward compatible with ANSI-C although not on whether they MUST be.

The extensions cover a number of different areas.   In principle the
extensions appropriate to each area would be orthogonal to those of other
areas, and would be described in separate chapters of the final report.   
In practice there are a few more global issues that impact how
we attack a number of separate areas.   One is whether to
invent new operators, in conventional operator notation or in 
functional notation; that affects the shape of extensions for IEEE arithmetic,
complex arithmetic, and arrays.

Who decides which areas to cover?  That's easy - areas get worked on if
there are people interested in working on them.   Proposed 
areas don't get worked on if nobody who comes to meetings is interested in 
them.

In the end NCEG as a whole will presumably insure that all proposed extensions
are self-consistent enough that they could all be implemented in one language.
Until that time, the groups work fairly independently between meetings.

Presumably after a report is finalized, interested parties will implement
the parts they are interested in, in various compiler products.  For instance,
I am hopeful that the whole report's extensions will be implemented in GCC.
Zortech has already implemented an early draft of the IEEE extensions.

Of course, anybody can implement any specification at any time, and anybody
can require products purchased to meet any specification.   But I would hope
that implementations would mostly wait until the report nears final form,
and that purchasers would not request "conformance" for some time after the
report is published.

NCEG is not producing a standard, after all.  Parts of the NCEG report that
prove their value by being implemented several times with good effect are
presumably candidates for the next version of ANSI-C.   Some people even
think that NCEG extensions should be consistent with incorporation into C++,
which strikes me as a rather different language in scope - the difference
between a low-level machine-oriented language and a high-level application-
oriented language.
So I'm not particularly concerned about incorporation into ANSI-C or C++.
Standards are defined by widespread acceptance, which can occur before or
after formal standardization.

Why bother then?  Extensions in the areas of IEEE conformance, complex
arithmetic, aliasing, and array processing will occur regardless of whether
there is a public NCEG effort or not.  If the effort is not public, it will
occur in private and may be haphazard and inconsistent.   
Worse, in the current climate of
uncertain intellectual property rights, somebody might lay proprietary claim to 
language extensions that I might consider obvious.

Public efforts have the burden and benefit of sidewalk superintendents with
various agendas, some quite helpful and others less so.  
I wished there were more
participation from the producers and consumers of mathematical software, but
they don't have quite the immediate incentive of the producers of compilers
and the hardware to be compiled for, so in NCEG 
there are quite a few more of the latter groups than the former.   Some have
an understandable resistance to any innovation that would tend to shorten their
products' lifetimes or increase their costs in developing the next generation.

============================================================================

And now for something that's somewhat different:

Another aspect that's particularly relevant to IEEE extensions is that many
people perceive no demand for them.  Demand builds up very gradually, but it
has been gratifying to me to begin to hear that some customers are beginning to
demand that Sun's competitors supply the same rudimentary IEEE support that has
been in Sun's compilers for several years.   
But before that feedback started to occur I had to operate somewhat on faith
that customers would find better IEEE support useful if it were available.

Closely related to this is the benchmark-driven marketing that sells a lot
of computers and quite a few compilers these days.  Benchmarks by their nature
tend to exercise the least interesting parts of systems, namely the parts that
work the same on every possible system, and so don't tend to exploit the
differences that make one system fundamentally better than another.

The producers of mathematical software work to a different paradigm.
Their goal is to produce robust portable efficient code.  
"Portable" increasingly means "among IEEE systems."  "Robust" encompasses
a wide domain of applicability and graceful degradation near the boundary.
Thus the interesting part
is the boundary cases, since realistic applications often end up on the
boundaries unexpectedly.
How well the boundary cases are treated determines how you
code the normal case, which affects performance at a very high level, because
it determines which algorithms can be effectively exploited.
Benchmarks that measure properties important for mathematical software 
production aren't too common but are increasing; a few are paranoia, pirats,
the IEEE test vectors, BeEf, FPV.