Date: Thu, 14 May 1998 10:55:49 +0300 (IDT) From: Eli Zaretskii To: Eric Rudd cc: djgpp AT delorie DOT com Subject: Re: Code to Fix sinh() in libm.a In-Reply-To: <355A204B.3B8A78EF@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 13 May 1998, Eric Rudd wrote: > 1. The libc.a routines are terse and efficient, but not always accurate. That is correct. Math functions in libc.a only implement the ANSI-standard functions, and they are meant to be used in programs which don't care much about FP accuracy. Serious FP programs should be linked with -lm. As a matter of fact, the libc math functions aren't even 100% ANSI, since they don't always set errno when some FP calamity happens. Caveat emptor. (DJGPP veterans may remember the flood of questions in the v1.x days asking about unresolved externals when using `sin' or such likes, just because the user didn't say -lm. Well, math functions in libc.a are meant to satisfy these users, and these users only.) > To solve the problems with poor accuracy for special arguments, certain > alternate forms can be used. For instance, the x87 coprocessor has > special machine instructions for exp(x)-1 and ln(x+1) that preserve good > relative precision for small x, and sinh(x) can be stably computed from > an accurate exp(x)-1 routine. 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. A case in point is the behavior of the functions for exceptional values of arguments. ANSI standard requires that the functions set errno and not blow up the program. In addition, most environments I've seen (including even Borland's) arrange for a special function (called `matherr') to be called to handle problems in math functions. If you use machine instructions without ``wasting time'' on checking the arguments and/or results for exceptional values, and don't look at the coprocessor status bits, these goals are tricky to meet. So some of the waste is IMHO necessary for a good math library. > I considered the following routines in libc.a unacceptable, and have > rewritten them: cosh exp tanh asin acos hypot acosh atanh asinh sinh. I > also wrote C-callable routines to compute exp(x)-1 and ln(x+1), since > those functions are generally useful. Please consider submitting these changes to DJ Delorie for inclusion in future DJGPP releases. > Since I have not had > time to test them extensively, I didn't consider them to be ready for > public use. I ran ELEFUNT on some of them, but I don't consider that a > sufficient test. Nevertheless, I think you should submit them. The existing math functions were also tested with the few test suites in djtst, so if your changes pass them, I don't see why should you worry. > However, I would be happy to make the code available for beta testing. > (What is the best way to do this? The routines, compressed, are about > 7k) Upload to ftp://ftp.delorie.com/incoming/ and send a message to DJ Delorie telling him about your upload.