Menu
▾
▴
gnuplot-beta
|
From: Per P. <per...@ma...> - 2006-09-28 20:55:01
|
On Sep 28, 2006, at 21:21, Dan wrote: > That shouldn't be too bad, but it will require a little bit of time > because I don't know autoconf so well and don't have too much free > time at the moment. > > http://www.gnu.org/software/autoconf/manual/html_node/ > Runtime.html#Runtime > > i.e., inside autoconf, check if HAVE_GAMMA, if so then do > AC_RUN_IFELSE() and then appropriately define something like > GAMMA_IS_LNGAMMA. > > Per, if you are fluent in autoconf language, maybe you could do > such a thing in a few minutes. I'm afraid that my name, fluent, and autoconf doesn't really belong in the same sentence:-/ I could have a go at it anyhow, but it would have to wait until the end of next week... Per |
|
From: Per P. <per...@ma...> - 2006-09-28 21:06:13
|
On Sep 28, 2006, at 21:21, gnu...@li... wrote: > >> there is no mention of a variable signgam. > > And that's a solid bug in any OS math library that purports to > implement > C99 or any recent level of Unix standard compliance. lgamma() is > required to be there, and it's equally required to have a signgam > to go > with it. Mentioned or not, it is present in my ppc/math.h, and I think we have shown it to be broken on Intel based Macs. Chris, do you have some time to file a bug with Apple? http://bugreport.apple.com /Per |
|
From: Daniel J S. <dan...@ie...> - 2006-09-28 21:20:52
|
Per Persson wrote: > On Sep 28, 2006, at 21:21, gnu...@li... > wrote: > > >>>there is no mention of a variable signgam. >> >>And that's a solid bug in any OS math library that purports to >>implement >>C99 or any recent level of Unix standard compliance. lgamma() is >>required to be there, and it's equally required to have a signgam >>to go >>with it. > > > Mentioned or not, it is present in my ppc/math.h, and I think we have > shown it to be broken on Intel based Macs. I'm not so certain we have shown that it is broken. My point is that signgam has no relation to lgamma() anymore in the context of C99. I'll make a guess that if you grep lgamma, the function doesn't reside in math.h. It is in tgmath.h. signgam probably is hanging around the header world because it is intendend for the legacy version of gamma() which used it. So, if Chris were to try using the combination of gamma() with signgam (not the combination of lgamma() and signgam which is the prefered function as gnuplot is currently programmed) then that would be a bug. In the patch I've removed the following: #if defined(GAMMA) && !HAVE_DECL_SIGNGAM extern int signgam; /* this is not always declared in math.h */ #endif Such a thing can only lead to problems if the idea is to be C99 compliant. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-09-28 21:24:46
|
I should clarify: > So, if Chris were to try using the combination of gamma() with signgam [and the results are incorrect] then that would be a bug. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-09-28 21:41:09
|
On Thursday 28 September 2006 02:30 pm, Daniel J Sebald wrote: > > I'm not so certain we have shown that it is broken. My point is that > signgam has no relation to lgamma() anymore in the context of C99. You are spouting nonsense. ISO/IEC C99 (including Annex F, "IEC 60559 floating-point arithmetic") and POSIX 2001 (IEEE Std 1003.1:2001) require lgamma() to provide signgam as an extern int I quote from the document "Rationale for International Standard Programming Languages C Revision 5.10 April-2003" 7.12.8.3 The lgamma functions New feature for C99. Since the mathematical gamma function increases in value so quickly (it is around 10306 for an argument of only 170), the logarithm of gamma extends the useful domain. Also, for computing combinations and permutations, it is the quotient of the (potentially large) gammas that is needed; taking differences of the lgammas instead allows for calculations without overflow. In Single Unix, a call to lgamma sets an external variable, signgam, to the sign of gamma(x), which is 1 if x < 0 && remainder(floor(x), 2) != 0. Note that this specification does not remove the external identifier signgam from the user's name space. An implementation that supports lgamma's setting of signgam as an extension must still protect the external identifier signgam if defined by the user. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-09-28 22:16:41
|
Ethan Merritt wrote: > ISO/IEC C99 (including Annex F, "IEC 60559 floating-point arithmetic") > and > POSIX 2001 (IEEE Std 1003.1:2001) > > require lgamma() to provide signgam as an extern int I don't necessarily read it that way. The language is not clear on that. I'll interject my interpretation in the quote: > I quote from the document > "Rationale for International Standard Programming Languages > C Revision 5.10 April-2003" > > 7.12.8.3 The lgamma functions > New feature for C99. Since the mathematical gamma function increases in > value so quickly (it is around 10306 for an argument of only 170), the > logarithm of gamma extends the useful domain. Also, for computing > combinations and permutations, it is the quotient of the (potentially > large) gammas that is needed; taking differences of the lgammas instead > allows for calculations without overflow. In Single Unix, a call to > lgamma sets an external variable, signgam, to the sign of gamma(x), > which is 1 if x < 0 && remainder(floor(x), 2) != 0. OK, here's the first mention of signgam. Is it stating that signgam is supposed to be present and related to lgamma()? Not directly, and for that reason I'm not sure that is what is meant. What is "Single Unix"? Is that the C99 standard? Or is this referring to some outside definition, i.e., some legacy definition? If that is the case, then all this sentence is stating is somewhere in the community there is an implementation of lgamma() which sets something called signgam. Note that this > specification does not remove the external identifier signgam from the > user's name space. What does this sentence say? It says that the definition is not specifically calling for the removal of signgam from the name space. I.e., it is allowed to hang around. (Unfortunately that is the source of confusion.) > An implementation that supports lgamma's setting of > signgam as an extension must still protect the external identifier > signgam if defined by the user. Why would they say "an implementation that supports" if the standard is to always support it? All this sentence is saying is that the "signgam" must be protected if the user defines such a variable. I still haven't seen anything that specifically calls out that in C99 lgamma() must or should support signgam. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-09-28 22:24:54
|
On Thursday 28 September 2006 03:26 pm, Daniel J Sebald wrote: > Ethan Merritt wrote: > > ISO/IEC C99 (including Annex F, "IEC 60559 floating-point > > arithmetic") and > > POSIX 2001 (IEEE Std 1003.1:2001) > > > > require lgamma() to provide signgam as an extern int > > I don't necessarily read it that way. The language is not clear. Those were two separate statements. (1) C99 and POSIX 2001 standard require it. (2) The rationale is given in the associated C99 doc I quoted. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <br...@ph...> - 2006-09-29 19:58:03
|
Daniel J Sebald wrote: > OK, here's the first mention of signgam. Is it stating that signgam > is supposed to be present and related to lgamma()? Not directly, and > for that reason I'm not sure that is what is meant. What is "Single > Unix"? The Single Unix Specification. That's the definition of what it means for an operating system to be "Unix" (or compatible to it), these days. Google finds it. > I still haven't seen anything that specifically calls out that in C99 > lgamma() must or should support signgam. That's because it's not there. I stated this as fact from memory, but it turned out to be wrong on re-reading the document. |
|
From: Daniel J S. <dan...@ie...> - 2006-09-30 09:14:39
|
Hans-Bernhard Br=F6ker wrote: >>I still haven't seen anything that specifically calls out that in C99 >>lgamma() must or should support signgam. >=20 >=20 > That's because it's not there. I stated this as fact from memory, but=20 > it turned out to be wrong on re-reading the document. OK... Well, the autoconf for running a program really wasn't too bad. For thos= e interested: dnl check, if gamma is log of gamma. if program dnl compiles and gamma(2.0) < 0.5 is false, then dnl simply say "gamma is gamma", otherwise define dnl GAMMA_IS_LNGAMMA AC_LANG(C) AC_RUN_IFELSE( [AC_LANG_PROGRAM([#include <math.h>],[exit(gamma(2.0) < 0.5);])], [ echo "gamma is gamma" ], [AC_DEFINE(GAMMA_IS_LGAMMA,1,[ Define if gamma() present and is log gamma= ])] ) I mildly suggest the most recent patch be added for 4.2. I think it is e= asier to simply add this patch than it is to explain the gamma-was-once-n= at-log-gamma confusion to a package or software maintainer. There is a g= ood chance, I think, someone will get bit by this, and we'd be saving him= or her a lot of time and headache. It's a very straightforward patch now... on SourceForge. Dan PS: I've verified this by slowly stripping away definition precedence, i= .e., #undef HAVE_TGAMMA, #undef HAVE_LGAMMA_R, #undef HAVE_GAMMA, etc. |
