Date:	Sun, 17 May 1998 14:02:31 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Eric Rudd <rudd AT cyberoptics DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: Code to Fix sinh() in libm.a
In-Reply-To:	<355B6619.42250062@cyberoptics.com>
Message-ID:	<Pine.SUN.3.91.980517140200.14173G-100000@is>
MIME-Version:	1.0

On Thu, 14 May 1998, Eric Rudd wrote:

> 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.

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.

> 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.

Please do.  IMHO, the math library functions in DJGPP didn't get as
much attention as I personally think they should have (although some
of them were fixed in v2.01, and others will be fixed in v2.02).

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 can make this
version available for you if you want.

- Raw text -