Date: Sun, 17 May 1998 14:02:31 +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: <355B6619.42250062@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.