No subject

[uunet!research.att.com!sesv]

I differ with Donn Terry on whether the IEEE Posix group should
get involved with math libraries & floating point in general.
P1003.* should *not* tackle the problem:
	a) As of last year, the bulk of the P1003.1 working group
	   was not interested in the topic.  Most members
	   were not heavy-duty floating point programmers, and
	   certainly not numerical analysts.
	b) There are too many math library standards/de facto standards in
	   existence already.  For a C binding, this includes
	   ANSI C, XPG 2, XPG 3, SVID/1986, SVID/1989, 4.3BSD ...
	   + someday NCEG.  

Suppose Posix (P1003.1) did get involved.  At a gross simplification,
there are two possibilities:
	1) P1003.1's interface is *exactly* the same as
	   one of the other standards.  There is little (no?) benefit
	   in making more paper.  (we run the risk that later
	   on the standards drift out of sync)
or worse,
	2) P1003.1 innovates & produces yet another interface.
	   This means that the poor application developer (and
	   math library implementor) has yet another standard to
	   worry about.   In System V, we have already functions which
	   give different results (e.g., HUGE versus HUGE_VAL)
	   depending on compilation options.  Adding yet
	   another #ifdef to source code isn't a help, it only
	   adds complexity.  
	   If all the other standards groups would say, ``we will 
    	   adopt whatever P1003.1 does'', then yes, the situation
	   would get better.  I don't believe that will happen.
	     

My recommendation for IEEE Posix/P1003.1 is to add, at most,
a requirement of the form, ``The library interfaces
defined in standard XXXXX-19xx shall be supplied'' to the
Posix standard.  We need one standard, not many.  Wherever
possible, inter-standards coordination should be of the form
``I'll cover X, you cover Y''.  
Who would object as a user or vendor if in a far distant future
that ANSI or NCEG defined the interfaces and
XPG/SVID/BSD/... adopted them verbatim? 
	
I wrote a note on exactly this topic (IEEE P1003.1 document N190, 90/01/06
distributed to the P1003.1 working group and with the January IEEE
P1003.1 mailing).  I received zero feedback.  This strengthens my
belief that this is not a problem for P1003.1 to attack.  P1003.1
has plenty of other work.

I share Donn's frustration with the multitude of standards, but 
think the Posix group should follow/encourage rather than lead.

Steve Sommars
AT&T Bell Labs