Ethan Merritt wrote:
> On Monday 25 September 2006 01:08 pm, Hans-Bernhard Br=F6ker wrote:
>=20
>>CM wrote:
>>
>>>I suppose this means that the next question from gnuplot's side of
>>>things is "Should we fiddle with auto configuration to work around
>>>this?"
>>
>>No. The next question from our side is: when will Apple fix this bug
>>in their implementation of gamma()? Only if the answer to that is
>>something equivalent to "never" it makes sense to discuss
>>workarounds.
>=20
>=20
> Yes, but...
> The state of gamma function implementations has changed a bit since
> gnuplot was first designed. Here is an excerpt from the current
> documentation:
>=20
> HISTORY
> 4.2BSD had a gamma() that computed ln(|Gamma(|x|)|), leaving the si=
gn
> of Gamma(|x|) in the external integer signgam. In 4.3BSD the name w=
as
> changed to lgamma(), and the man page promises
> "At some time in the future the name gamma will be rehabilitated
> and used for the Gamma function"
> This did indeed happen in 4.4BSD, where gamma() computes the Gam=
ma
> function (with no effect on signgam). However, this came too late, a=
nd
> we now have tgamma(), the "true gamma" function.
>=20
>=20
> The point being that since about 1999 many systems have had a third
> option, tgamma(), in addition to the gamma() and lgamma() functions
> that gnuplot's autoconfigure checks for. The syntax and usage of
> tgamma(), if present, may be more reliable than those of gamma().
Oy, tgamma? Well, it may make life simpler if tgamma is ubiquitous. Her=
e is what I get on whatever is on FC3:
configure:7256: checking for gamma
[snip]
configure:7344: result: yes
configure:7256: checking for lgamma
[snip]
configure:7344: result: yes
configure:7256: checking for tgamma
[snip]
configure:7344: result: yes
configure:7256: checking for foogamma
[long snip]
configure:7344: result: no
Chris, is there a tgamma on your system?
Dan
|
