From: Eric Rudd Newsgroups: comp.os.msdos.djgpp Subject: Re: Code to Fix sinh() in libm.a Date: Mon, 18 May 1998 10:01:07 -0500 Organization: CyberOptics Lines: 50 Message-ID: <35604D33.B8353462@cyberoptics.com> References: Reply-To: rudd AT cyberoptics DOT com NNTP-Posting-Host: rudd.cyberoptics.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Eli Zaretskii wrote: > I agree that using coprocessor-specific features might help, sometimes > help a lot. But the tricky part is to do that without breaking > ANSI/IEEE compatibility, since even 80-bit numbers can generate > exceptional results, like with sqrt(-1). So some testing of the > arguments and the results is still required, in order to set errno or > call matherr. If the tests are biased in favor of high speed for normal arguments at the expense of error-handling speed, they can be pretty quick. > FYI: I have found the latest version of libm sources on the net, and > I'm slowly working on adapting them to DJGPP, hopefully for v2.02. > This version has some accuracy-related fixes in low-level functions > such as expm1, but otherwise it hasn't change much. I had noticed that their old expm1 routine was pretty bad. They simply computed exp(x) and then subtracted one. The relative accuracy of that scheme is terrible for arguments near zero. This was, I believe, the origin of the problems with sinh() that started this whole thread. > I can make this version available for you if you want. I would appreciate receiving either the new libm code or the URL. However, when I saw the problem with expm1, I began to regard the entire libm package with suspicion, and decided that it would be easier to continue polishing my own routines than to subject the libm code to the meticulous scrutiny needed to catch more problems like that. But the new libm routines may be useful as a cross-check, and to see if they have any ideas worth using. I have a question regarding the state of the coprocessor control register. I noticed that in DJGPP v2.01, overflows are masked. Since the IEEE floating-point formats are capable of representing infinity, this is appropriate. Thus, overflow to infinity is handled as gracefully as underflow to zero. The question I have is whether this state of the control word can be counted on in future versions of DJGPP, or if I must treat infinite results as errors. The ANSI C standard does not appear to resolve this question. For instance, in 7.5.4.1 (for the exp() function), it only says that "a range error occurs if the magnitude of x is too large." If infinities are allowed, then no argument will be "too large". Furthermore, in 7.5.4.4 (the log() function), it states that "a range error *may* occur if the argument is zero." (emphasis mine) I take this to mean that a range error is not *required* for infinite results. But none of this will work if I can't count on the state of the x87 control register. -Eric Rudd rudd AT cyberoptics DOT com