Mon, 16 Nov 1992 21:56:18 GMT

Related articles |
---|

IEEE arithmetic handling jim@meiko.co.uk (1992-11-11) |

Re: IEEE arithmetic handling tmb@arolla.idiap.ch (1992-11-16) |

Re: IEEE arithmetic handling eggert@twinsun.com (1992-11-16) |

Re: IEEE arithmetic handling bill@amber.csd.harris.com (1992-11-16) |

Re: IEEE arithmetic handling jlg@cochiti.lanl.gov (1992-11-17) |

Re: IEEE arithmetic handling eggert@twinsun.com (1992-11-17) |

Re: IEEE arithmetic handling tmb@arolla.idiap.ch (1992-11-18) |

Re: IEEE arithmetic handling bart@cs.uoregon.edu (1992-11-19) |

Re: IEEE arithmetic handling bill@amber.csd.harris.com (1992-11-20) |

Re: IEEE arithmetic handling bill@amber.csd.harris.com (1992-11-20) |

[2 later articles] |

Newsgroups: | comp.compilers |

From: | bill@amber.csd.harris.com (Bill Leonard) |

Organization: | Harris CSD, Ft. Lauderdale, FL |

Date: | Mon, 16 Nov 1992 21:56:18 GMT |

Keywords: | arithmetic |

References: | 92-11-041 |

jlg@cochiti.lanl.gov (J. Giles) writes:

|> Unfortunately, the Fortran standard does not conform to

|> IEEE (in fact, it conflicts with it in some places - like with regard

|> to negative zero). And the Fortran standard does not require the same

|> conversion accuracy as the IEEE floating point standard.

I have a couple of nits to pick with this. First, Fortran does not

*conflict* with the IEEE vis-a-vis negative zero. It merely says that the

processor must never *output* a negatively-signed zero. That doesn't mean

that variables in the program cannot contain such a value.

Second, not requiring conversion accuracy in Fortran could hardly be called

a conflict. Fortran doesn't require *any* accuracy, precisely so that it

WON'T conflict with any arithmetic standard, and so that it will be

possible to implement Fortran on a wide variety of machines, whether or not

they are IEEE.

Were Fortran to require IEEE accuracy, then you would only see Fortran

implemented on IEEE machines (or machines that exceeded the IEEE

requirements). That would make a lot of Fortran users unhappy.

jim@meiko.co.uk (James Cownie) writes:

*> This is a less significant difference than some of the others, in*

*> particular Fortran definition of NINT and ANINT directly conflicts with*

*> the IEEE definitions of the same functions. *

Since Fortran predates the IEEE standard by several decades, it would be

more accurate to say that the IEEE standard conflicts with Fortran, not the

other way round. In particular, if the IEEE standard attempts to define

the semantics of Fortran intrinsic functions, it is stepping outside its

bounds. But I don't think that's what the IEEE standard does. It does not

specify *anything* about how one accesses the features of the IEEE

floating-point hardware from any particular language.

I think one must conclude, though, that the IEEE standards committee did a

poor job if they defined functions that popular programming languages don't

provide, or functions whose semantics don't match those of existing

languages. But one can hardly blame Fortran for not matching a standard

that had not even been conceived when the original Fortran standard was

developed.

*> Another area where IEEE seems never to be implemented correctly by*

*> compilers is in the handling of Not a Numbers (NaNs). *

*> *

*> In the IEEE standard NaNs are values which can be encoded into a floating*

*> point variable, which represent the concept that it is not a reasonable*

*> number. (They are generated for operations such as sqrt(-ve), 0.0/0.0*

*> etc.) IEEE specifies that a NaN is unordered with respect to anything*

*> else, EVEN ITSELF. Therefore ALL comparisons involving floating variables*

*> MUST be generated by the compiler WITHOUT introducing logical negation,*

*> since in the face of NaNs (and their unordered relationship with other*

*> numbers)*

*> *

*> (.NOT. (X .LT. 2.0)) does NOT imply (X .GE 2.0)*

I think this is just another area where the IEEE semantics don't match

the semantics of most programming languages. In this case, they don't

even match the semantics users often expect. Most people *would* expect

that (.NOT. (X .LT. 2.0)) implies (X .GE 2.0). There must be millions

of IF-statements out there whose ELSE clauses rely on such things. If

a program is going to break because (X .GE 2.0) is transformed into

(.NOT. (X .LT. 2.0)), then I strongly suspect the program is written

incorrectly in the first place.

Before I get flamed, I will certainly acknowledge that there are lots of

sophisticated programmers who want, and need, to take advantage of IEEE

semantics. The mistake, I think, is to try to overload long-established

semantics of long-existing programming languages for situations that

millions of users have no interest in.

*> Similarly (and I've never seen this handled right in an optimising*

*> compilation),*

*> *

*> IF (X .ne. X) THEN*

*> print *,'X is a NaN'*

*> ELSE*

*> print *,'X is a number'*

*> ENDIF*

Our compilers DO handle this correctly, but the special case is only for

equality and non-equality tests. (Yes, our compilers do optimize --

heavily.) It doesn't seem reasonable to special-case other relationals,

because one could hardly rely on a .FALSE. answer meaning you did, or did

not, have a NaN.

--

Bill Leonard

Harris Computer Systems Division

2101 W. Cypress Creek Road

Fort Lauderdale, FL 33309

bill@ssd.csd.harris.com

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.