Forwarded Re: optimizing floating point (fwd)

[Jerry Huck]

I forwarded the first wave of the "a+b+c" optimization discussion to
some people here at HP (and beyond) and got the following request to
post a response.  cc Ed if you want him to see it.  I don't agree with
this, I'm only the messenger.

Jerry

> 
> Jerry-
> 
>      Could you forward this response from Ed Barkmeyer of NIST to the
> numeric-interest mailing list that spawned the list of notes last week?
> I forwarded it to the X3T2 members that work on the LCAS draft standard,
> and Ed wants to reply.  Thanks,
>                                               - Carl
> 
> From edbarkacme.nist.gov Tue May 12 13:03 PDT 1992
> Date: Tue, 12 May 92 15:55:10 EDT
> From: edbarkacme.nist.gov (Ed Barkmeyer)
> Message-Id: <9205121955.AA01860aradio.cme.nist.gov>
> To: cdbahpcllak.cup.hp.com
> Subject: Re:  FYI - optimizing floating point
> Status: RO
> 
> I would appreciate it if you would convey the following to the group
> whence this set of comments came:
> 
> There are several premises on which this whole discussion of conformance
> of optimizing compilers depends, and none of these premises seems to be
> supported by anything appearing in the language standards:
> 
> (1) that the datatype declared by REAL in Fortran and float/double in C
> is the machine-defined floating-point arithmetic,
> 
> (2) that the meaning of the arithmetic operations of either the C or Fortran
> language is defined in terms of a model of floating-point contained in or
> referenced by the language standard,
> 
> (3) that the result of a literal interpretation of the program as written 
> (the "unoptimized" version) is always well-defined.
> 
> It is my personal view that the kind of code which attempts to determine
> parameters of the machine arithmetic by trick sequences which depend on one
> or more of the above assumptions is nothing more than cute system-dependent
> trick code.  It is precisely the kind of thing that is viewed with distaste
> by the senior practitioners of any other computer application.  And the
> evidence is that the vendors of mathematical libraries have exactly the
> kind of portability and compiler-dependency problems that one would expect
> from this kind of coding.
> 
> To be fair, I understand the NEED for a strong model of REAL arithmetic
> and the availability of the parameters of that model to the programmer.
> I just think they are going about it the wrong way.  The question in my
> mind is:  To what extent does IEEE 754 solve this problem?  To what extent
> does the proposed LIA (ISO 10967) solve this problem?   Should either or
> both of them be modified to finish the job?  Shall we demand that the
> language standards use and/or require one or the other or both of them?
> 
> In other words, instead of grousing about the vagaries of compilers, why
> don't these people contribute to the active standardization processes in
> this area?
> 
> -Ed
>