delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/09/05:26:50

Date: Wed, 9 Jun 1999 11:36:12 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Eric Rudd <rudd AT cyberoptics DOT com>
cc: DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject: Re: libm sources from cyberoptics
In-Reply-To: <375D4DF1.5F3B39F9@cyberoptics.com>
Message-ID: <Pine.SUN.3.91.990609113455.11862J-100000@is>
MIME-Version: 1.0
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019