X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
Date:	18 Feb 2004 07:48:54 +0200
Message-Id:	<u4qtpj5tl.fsf@elta.co.il>
From:	Eli Zaretskii <eliz AT elta DOT co DOT il>
To:	Eric Rudd <rudd AT cyberoptics DOT com>
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<40312BCC.1080507@cyberoptics.com> (message from Eric Rudd on
	Mon, 16 Feb 2004 14:45:00 -0600)
Subject:	Re: C99 Functions Under Development and Checkout
References:	<c DOT 223440a1 DOT 2d5fdc07 AT aol DOT com> <40312BCC DOT 1080507 AT cyberoptics DOT com>
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

> Date: Mon, 16 Feb 2004 14:45:00 -0600
> From: Eric Rudd <rudd AT cyberoptics DOT com>
> >   -------------------------------------------------------------------------
> >   B L U N D E R S  C O M M I T T E D  B Y  F U N C T I O N S  I N  L I B C
> >   -------------------------------------------------------------------------
> >  
> >
> This whole topic is really depressing, since these were not careless 
> oversights, but rather philosophical differences:  when I wrote these 
> functions I carefully considered what would be the consequences of 
> various types of behaviors for exceptional inputs.  Thus, since an 
> argument of NaN is outside the mathematical domain of definition of a 
> function, I concluded that warning the caller by setting errno to EDOM 
> was the prudent thing to do.  Similarly, atan(+Inf,+Inf) is not defined 
> in the mathematical sense, so I return NaN and EDOM there, as well.
> 
> Then came C99, which stipulated, for instance, that atan(+Inf,+Inf) = 
> pi/4.  This is tantamount to saying that Inf/Inf = 1.  I made public 
> objections to some of these things when C99 was out for review, but the 
> C99 committee neither changed the draft standard nor gave a significant 
> explanation of why it kept things as they were.  Thus, one could as well 
> speak of "Blunders committed by IEEE 754 and C99".

As someone who was involved, albeit as an interested bystander, in
Eric's efforts to produce fast, reliable, and standard-conforming
functions, I largely agree with these sentiments.

So I think that it is not too awful that we will continue to have
these deviations from C9x.  Unless, of course, someone steps forward
and volunteers to modify the math functions in libc, at least in some
of the cases, to follow C9x more closely, but without sacrificing
performance.  If such a volunteer presents herself, I suggest that we
first establish an order of priorities to fix these deviations: which
ones are more urgent, which ones we don't want to fix because we think
C9x rulings are incorrect, etc.

> on the Pentium 4, the coprocessor handles NaNs, etc. through an
> exception mechanism that is as much as 300 times slower than normal
> execution.

Do you have details about this?  Like more precise timings, the
reasons why it is so slow, etc.?

- Raw text -