From: Message-Id: <200303171820.h2HIKtd03676@speedy.ludd.luth.se> Subject: Re: elefunt results In-Reply-To: <3E677FE9.4070703@cyberoptics.com> "from Eric Rudd at Mar 6, 2003 11:05:45 am" To: djgpp-workers AT delorie DOT com Date: Mon, 17 Mar 2003 19:20:55 +0100 (CET) CC: rudd AT cyberoptics DOT com X-Mailer: ELM [version 2.4ME+ PL78 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-MailScanner: Found to be clean Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk According to Eric Rudd: > ams AT ludd DOT luth DOT se wrote: > > >Alas there seems to be some failures. I'm not planning to try to > >understand or correct them, but I'm reporting it in case somebody else > >likes to examine it. > > > I will comment on these results, since I wrote the libc elementary math > functions. > > >How current are these test anyway? All capitals is a little weird; > >makes me think of the 80ties. > > > As I understand, these tests *are* old; they were translated from > FORTRAN. However, mathematics is not invalid just because it is old. > > These ELEFUNT errors occurred because of conscientious design choices on > my part, rather than unexpected bugs. Informed and responsible > numerical analysts don't always agree on the handling of exceptional > cases, and these are some of the cases where I disagreed with the > philosophy of ELEFUNT. Below are my explanations of why these error > messages are triggered: > > >ttan.djl, error message missing: > >TAN WILL BE CALLED WITH THE ARGUMENT 9.0072e+15 > > THIS SHOULD TRIGGER AN ERROR MESSAGE > > > > > > TAN RETURNED THE VALUE 1.6063e+00 > > > >tsin.djl, error message missing: > > SIN WILL BE CALLED WITH THE ARGUMENT 9.0072e+15 > > THIS SHOULD TRIGGER AN ERROR MESSAGE > > > > > > SIN RETURNED THE VALUE -8.4893e-01 > > > > > Accurate results should not be expected for trig functions of large > arguments, since tiny perturbations of the arguments give rise to large > perturbations of the results. However, these large but finite arguments > are not outside the mathematical domain of definition of the functions, > so I felt that a domain error (EDOM) was not called for in this case. > It is actually possible to return accurate results for large arguments, > if multiple precision is used to reduce the arguments. libm does this, > but one pays a price in execution time, which I thought was not > warranted, especially if those arguments are contaminated by roundoff > error from previous computation. Those who want trig routines that can > perform such feats can use libm, but we needed an alternative for the > user who wanted speed. (I had to give up very little in accuracy to get > that speed, thanks to the excellent coprocessors on Intel machines.) My > choice was to use the built-in coprocessor value for pi to reduce the > arguments, and not flag an error. The trig functions of large arguments > are thus very inaccurate, but the argument reduction is identical for > all the trig functions, so they at least obey the usual identities, e.g. > sin^2 + cos^2 = 1. > > >tpower.djl, error message: > > ( 2.0000000e+00) ** (-1.0740000e+03) WILL BE COMPUTED. > > THIS SHOULD NOT TRIGGER AN ERROR MESSAGE > > > >pow(): Output of function out of range (ERANGE) > > THE VALUE RETURNED IS 4.9407e-324 > > > I chose to flag an error here because the result is denormalized. I > could have chosen to raise ERANGE only when a finite result gets > assigned a value of zero of infinity. However, when the results get so > small that they are denormalized, full precision is no longer attained. > In the case that ELEFUNT evaluated above, the result has only one bit > of significance left in it, and I felt that one ought to know about > that, since the answer is otherwise well defined in terms of the > arguments. The error is reported by setting errno, rather than > generating an exception, so one can easily ignore it. > > The difference between this case and the previous one is subtle: in the > former case, the results are what one calls "backward-stable," that is, > the error in the result (large though it may be) can be explained by a > small perturbation to the argument. In the latter, the result is not > backward-stable when it begins to underflow. Thank you for the explanation. To avoid further confusion about the failures I want to 1. Put the quote above in tests/libc/ansi/math/elefunt/readme.DJGPP. or 2. Put a link to the archived mail quoted above at delorie.com. If that's ok with you Eric. I prefer 1. I also want to commit the following patch as it makes it build and it makes the failures in sync with the output. Right, MartinS Index: djgpp/tests/libc/ansi/math/elefunt/makefile =================================================================== RCS file: /cvs/djgpp/djgpp/tests/libc/ansi/math/elefunt/makefile,v retrieving revision 1.2 diff -p -u -r1.2 makefile --- djgpp/tests/libc/ansi/math/elefunt/makefile 15 Jun 1999 07:27:55 -0000 1.2 +++ djgpp/tests/libc/ansi/math/elefunt/makefile 17 Mar 2003 18:00:39 -0000 @@ -72,7 +72,9 @@ else # no borland compiler, we use gcc LD = gcc LIBRARY_PATH := ../../../../../lib export LIBRARY_PATH - RUN = # how to run the executables + PATH := $(PATH);. +# RUN = # how to run the executables + RUN = redir -eo # how to run the executables ifdef DEBUG # don't use -O!! CFLAGS = -g -Wall -fno-builtin $(INCLUDE) $(DEFINES)