Mail Archives: djgpp/1998/05/14/19:31:05
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
- Raw text -