Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!MASIG1.OCEAN.FSU.EDU!mccalpin From: mccalpin@MASIG1.OCEAN.FSU.EDU ("John D. McCalpin") Newsgroups: comp.sys.sgi Subject: RE: exp(large numbers) on IRIS Message-ID: <8807071756.AA09822@masig1.ocean.fsu.edu> Date: 7 Jul 88 17:56:09 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Silicon Graphics has known about the pathetic behavior of the exp function for a long time, but they do not seem at all interested in doing anything about it.... As I understand it, they bought the compiler from Silicon Valley Software, and did an in-house rewrite of the intrinsic transcendental functions. The behaviour can be modified (though not corrected) by initializing the floating-point exception handler. You will need to add the following lines to the example code: #include! somewhere in declarations call setfpe (NOCOREDUMP, ZEROVALS) ! first executable statement This makes MOST underflows go gently to zero, but it does not fix the exp() problem. I don't know why the floating-point exception handler is not active by default.... I have to uses a fix to the exp() problem, I use x = min(x,88.0) x = max(-88.0,x) result=exp(x) or, in one line: result = exp(max(-88.0,min(x,88.0))) The constant 88.0 is the largest value which returns a correct result with 32-bit precision. I can't recall the number for 64-bit precision --- I think it is about 300. Now that the 4D's are the SGI's main interest, I would not count on getting any improvements to the SVS Fortran on the IRIS 3000's.... especially since they did not respond when the IRIS 3000 was their only entry. I suggest that you try a SUN machine. They have troubles, but at least the Fortran numerics are quite robust. John D. McCalpin mccalpin@nu.cs.fsu.edu