Mail Archives: djgpp-workers/1999/06/09/05:26:50
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.
- Raw text -