X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f Date: 18 Feb 2004 07:48:54 +0200 Message-Id: From: Eli Zaretskii To: Eric Rudd 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: <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 Precedence: bulk > Date: Mon, 16 Feb 2004 14:45:00 -0600 > From: Eric Rudd > > ------------------------------------------------------------------------- > > 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.?