From: Eric Rudd Newsgroups: comp.os.msdos.djgpp Subject: Re: Code to Fix sinh() in libm.a Date: Thu, 14 May 1998 16:46:01 -0500 Organization: CyberOptics Lines: 46 Message-ID: <355B6619.42250062@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: > > Please note that, apart from speed, there are other, no less important > objectives that a good math library must satisfy. One of them is > compliance to ANSI and IEEE standards, as well as to established > industry de-facto practice. Using coprocessor instructions might > trade some of these for speed. I agree that conformance to the ANSI C standard is important, and that is another reason I have not yet submitted my own routines for public use. The thing I noticed in the libm.a routines was that some (most notably e_hypot.c) were very tedious because they did not exploit the capabilities of the coprocessor. I don't mean to disparage such routines, since they were probably written for portability, but IMHO the elementary transcendental functions are a good place to sacrifice portability for performance. For instance, to continue with e_hypot.c as an example, the hypot function becomes rather awkward to implement strictly in double precision, because the intermediate result x^2 + y^2 can overflow or underflow, even if the result does not. If one holds the intermediate results in the coprocessor registers, with their larger dynamic range, the implementation becomes completely straightforward. A lot of the tests in the libm.a routines are to get around problems like these, which one doesn't have if intermediate results are held in coprocessor registers. For that matter, I don't think that use of coprocessor instructions interferes with ANSI compliance. I wasn't interested in "errno" for my own routines, since for me a traceback dump is more than adequate notice of the problem, but there's nothing to stop one from doing the added tests. I advocate using the machine to its fullest in order to make some of the tests unnecessary. The thing that drove me to write my own routines was neither lack of speed nor ANSI non-compliance, but that some functions were computed inaccurately by both the libc.a functions and the libm.a functions. For instance, the acos(x) function achieves only about 10 decimals of accuracy for the argument 0.99999999985 even with the libm.a routine. I would like to review the entire state of the elementary math functions for DJGPP, and the recent discussion in c.o.m.d. gives me additional incentive to do so. Stay tuned. -Eric Rudd rudd AT cyberoptics DOT com