Date: Wed, 9 Jun 1999 11:36:12 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Eric Rudd cc: DJ Delorie , djgpp-workers AT delorie DOT com Subject: Re: libm sources from cyberoptics In-Reply-To: <375D4DF1.5F3B39F9@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 8 Jun 1999, Eric Rudd wrote: > > 1) The biggest problem is that asin and acos return NaN for every > > argument. I probably did something stupid to get this, > > If it gave you trouble, it'll probably give trouble to dozens of other DJGPP > users, so I had better look into it -- but since they work fine for me, I'm > not sure how to proceed. Perhaps you could send me your object files. I will then compare them with mine, and we will take it from there. > Try assembling the routines with something like > > gcc -c asin.s -o asin.o > > instead of > > as asin.s -o asin.o I didn't use `as' directly, since I did notice the comments. I compiled everything like this: gcc -c asin.S (the capital .S causes GCC to run the preprocessor first). > > - exp2 and exp10 don't set it in both cases which test abnormal > > arguments; > > exp2 and exp10 properly set errno when I ran the Elefunt tests. They don't > show up in the .DJL files, however, because they are written to stderr > instead of stdout. Perhaps that is the problem. Nope, I redirected both streams to the same file. And I did see the messages in the other cases, so the redirection worked. Another mystery, I guess. Please send me your object files for exp2 and exp10 as well. > I decided to take the conservative route and flag a range error whenever the > result cannot be represented to full precision (that is, all denormal and > infinite results get flagged with ERANGE). Infinites should produce ERANGE, but I think denormals shouldn't. Denormals are simply the last resort of overcoming the limitations of the machine representation, and at least printf-family functions have no problems with them. > > - pow(-2, 0) and pow(-2, 2) do NOT set errno, whereas Elefunt > > says they should; > > There are some cases, such as pow(0., 0.) or pow(-2., inf), where there is > reasonable debate as to what should be returned, but I can't think of any > reason why we shouldn't have pow(-2.,0.) = 1. and pow(-2., 2.) = 4, with no > error return. I think there's a problem with Elefunt here. ANSI C says that pow(x,y) should raise EDOM if x is negative and y is not an integral value. So I guess these are okay. > However, what should sqrt(-0.) return? +0.? -0.? Hmm... I vote for a positive zero as the result of sqrt(-0.). > In particular, though the prevailing consensus is that 0^0 should be defined > as 1, my decision to raise EDOM for pow(0., 0.) was based on the fact that > it is mathematically-indeterminate. ANSI C says that a "domain error occurs if the result cannot be represented when x is zero and y is less than or equal to zero". Is 0^0 unrepresentable? > but a NaN is outside the mathematical domain of a function, is it not? It > would actually simplify many routines to simply pass NaNs on through. I would vote for passing them, since all other computations do. A program that wants to be sensitive to NaNs should have a lot of special code anyway, precisely for this purpose; setting errno won't save such programs. > > 5) floor, ceil and modf use static variables to store old control > > word, while the old code put them on the stack. This change > > makes functions non-reentrant. Is there a real reason to do > > that? > > There are a number of routines that are non-reentrant. If it is important > for them to be reentrant, I will have to fix them. I agree with DJ: we should not introduce new non-reentrant functions, unless making them reentrant bloats their code a lot. > Can we count on the coprocessor being in round-to-nearest mode? We probably can, if we document that. DJ? > I have documentation for sincos and powi at home, which I'll send to you > tomorrow. Thanks.