Mail Archives: djgpp/1998/05/14/03:56:12
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 <dj AT delorie DOT com> telling him about your upload.
- Raw text -