Re: [Fwd: Re: gnuplot numerical errors on Intel MacBook]

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> There may be more to this.  I see now that "signgam" is actually an
>> external as part of the math library I'm guessing. =20
>=20
>=20
> No need for guessing --- that's what you have libc/libm manpages for.
>=20
>  > So, if I
>=20
>> understand this, calling gamma() (i.e., the "old gamma" which is
>> actually ln gamma) will set the sign of the gamma function upon
>> calling gamma().  How is an optimizing compiler to know that?
>=20
>=20
> It doesn't have to.  signgam is a global variable, exported by the=20
> library, and the code reads it.

Right.  Well, there is also what Ethan pointed out.  The use of a global =
variable in a library isn't thread safe, so using lgamma_r() would be pre=
fered.

>=20
>> Anyway, maybe just avoiding the use of "signgam" in any way is best.
>=20
>=20
> We can't do that.  Not on platforms that don't sport a tgamma(), anyway.

And I'm wondering how many platforms that is.  If it is a small percentag=
e and getting smaller, then rewriting gnuplot's gamma function to be "tru=
e gamma" and not using signgam/lgamma would be a straightfoward approach.

Dan