gnuplot-beta — Developers and beta testers of new gnuplot code

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

[Per P. <per...@ma...>]

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

Check for gamma [Was: gnuplot numerical errors on Intel MacBook]

[Per P. <per...@ma...>]

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

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

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

Ethan Merritt wrote:
> On Thursday 28 September 2006 11:57 am, Daniel J Sebald wrote:
>=20
>>Hans-Bernhard Br=F6ker wrote:
>>
>>>Daniel J Sebald wrote:
>>>
>>> > So perhaps it has no meaning anymore for Apple's platform.
>>>
>>>That's not Appple's decision to make.
>>>
>>> > Why they would still have the variable in
>>> > the library if that were the case, I'm not sure.
>>>
>>>They must have it, and they must use it as defined in all
>>>applicable standards.
>>
>>I'm guessing the concept
>>is to move away from signgam, I believe, for which the
>>non-threadedness may have played a factor in their decision.
>=20
>=20
> Given that in order to be mathematically correct the sign=20
> information must be present *somewhere*, this leaves two options.
> (1) lgamma_r(double x, int *signp)
> (2) tgamma

That's why in the second version of the patch these two have precedence (=
tgamma higher than lgamma_r).  Using lgamma_r doesn't complicate matters.

But if there is some library out there that implements "gamma()" as the t=
rue gamma and inherently has sign information, that will work too.  One c=
an argue that would only be a tiny percentage of platforms, granted.

Dan

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

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 September 2006 11:57 am, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> > Daniel J Sebald wrote:
> >
> >  > So perhaps it has no meaning anymore for Apple's platform.
> >
> > That's not Appple's decision to make.
> >
> >  > Why they would still have the variable in
> >  > the library if that were the case, I'm not sure.
> >
> > They must have it, and they must use it as defined in all
> > applicable standards.
>
> I'm guessing the concept
> is to move away from signgam, I believe, for which the
> non-threadedness may have played a factor in their decision.

Given that in order to be mathematically correct the sign=20
information must be present *somewhere*, this leaves two options.
(1) lgamma_r(double x, int *signp)
(2) tgamma

The docs even say as much:

   "Since  using  a constant location signgam is not thread-safe,
    the functions lgamma_r() etc. have been introduced; they
    return this  sign  via the parameter signp."



=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

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

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>=20
>>Probably so.  If this is the most up-to-date documentation:
>=20
>=20
>>http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3=
/lgamma.3.html=20
>=20
>=20
>>there is no mention of a variable signgam. =20
>=20
>=20
> And that's a solid bug in any OS math library that purports to implemen=
t=20
> C99 or any recent level of Unix standard compliance.  lgamma() is=20
> required to be there, and it's equally required to have a signgam to go=
=20
> with it.
>=20
>  > So perhaps it has no meaning anymore for Apple's platform.
>=20
> That's not Appple's decision to make.
>=20
>  > Why they would still have the variable in
>=20
>>the library if that were the case, I'm not sure.
>=20
>=20
> They must have it, and they must use it as defined in all applicable=20
> standards.

Well, thanks for pointing out the standard, didn't know there was a C99 s=
tandard.  However, if this is the standard documentation at:

http://www.open-std.org/JTC1/SC22/WG14/www/standards

under WG14 N1124 (it's a PDF file), then I don't immediately see any indi=
cation that lgamma() requires there be an associated signgam variable.  I=
n fact, there is no such signgam in the document anywhere.  The documenta=
tion appears just as listed on the apple websight.

There isn't even a gamma() function in C99.  I'm guessing the concept is =
to move away from signgam, I believe, for which the non-threadedness may =
have played a factor in their decision.

So, that first patch I have on SourceForge is the C99 version (just tgamm=
a or lgamma).  The second patch is the "alright, we'll be nice to all you=
 behind the curve computer users out there" (which is probably somewhere =
near 99.73%) version.

Dan

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

[<br...@ph...>]

Daniel J Sebald wrote:

> Probably so.  If this is the most up-to-date documentation:

> http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/lgamma.3.html 

> 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.

 > So perhaps it has no meaning anymore for Apple's platform.

That's not Appple's decision to make.

 > Why they would still have the variable in
> the library if that were the case, I'm not sure.

They must have it, and they must use it as defined in all applicable 
standards.

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

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

Ethan Merritt wrote:
> On Thursday 28 September 2006 02:44 am, Daniel J Sebald wrote:
> 
>>/*
>>Order of preference and why:
>>
>>  tgamma() - It's the true gamma, perfect.
>>  gamma() - If there is a gamma() in the library and no tgamma()
>>there is a slim chance (now... who knows in the future?) that it is
>>the true gamma.  At run time we will check if it is true gamma or log
>>gamma.  If it is log gamma, it won't be used because signgam is not
>>thread safe.
>>  lgamma_r() - This is thread safe and will work.  Tempted to put
>>this at higher priority than gamma() but OK here for now. lngamma() -
>>Gnuplot's version of log gamma as last resort.  sgngam is local to
>>this code so is thread safe.
> 
> 
> No run-time changes of mind, please.
> Get it worked out correctly when the program is built and
> then run with it.

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.

Dan

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

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 September 2006 02:44 am, Daniel J Sebald wrote:
> /*
> Order of preference and why:
>
>   tgamma() - It's the true gamma, perfect.
>   gamma() - If there is a gamma() in the library and no tgamma()
> there is a slim chance (now... who knows in the future?) that it is
> the true gamma.  At run time we will check if it is true gamma or log
> gamma.  If it is log gamma, it won't be used because signgam is not
> thread safe.
>   lgamma_r() - This is thread safe and will work.  Tempted to put
> this at higher priority than gamma() but OK here for now. lngamma() -
> Gnuplot's version of log gamma as last resort.  sgngam is local to
> this code so is thread safe.

No run-time changes of mind, please.
Get it worked out correctly when the program is built and
then run with it.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

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

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

OK, I think I have this noodle soup figure out.  I put a new version of the gamma patch on SourceForge.  Below is the definitions which is the best way to get the logic across.  What this boils down to is the following:

Any workable combination of library gamma will do except signgam is never used to reconstruct the gamma function because it is not thread safe.  The patch will use gamma() in some cases but will do a run-time check to make sure it is the right type.  (The autoconf literature suggests doing that over AC_RUN_ELSEIF().)  If the thread safe lgamma_r() is present that is used.  Etc.

This patch should work in Chris' case.  The tgamma() takes top priority.  But even if Chris didn't have tgamma(), gamma() would be used, but the run-time check would indicate that gamma() is actually log gamma and then from there on gnuplot's internal gamma function would be used.  lgamma() wouldn't be used for reconstructing gamma.

Dan



/*
Order of preference and why:

  tgamma() - It's the true gamma, perfect.
  gamma() - If there is a gamma() in the library and no tgamma() there
	    is a slim chance (now... who knows in the future?) that it
	    is the true gamma.  At run time we will check if it is true
	    gamma or log gamma.  If it is log gamma, it won't be used
	    because signgam is not thread safe.
  lgamma_r() - This is thread safe and will work.  Tempted to put this
	       at higher priority than gamma() but OK here for now.
  lngamma() - Gnuplot's version of log gamma as last resort.  sgngam is
	      local to this code so is thread safe.

DO NOT USE:

#elif defined(HAVE_LGAMMA)
# define GAMMA(x) (gp_exp(lgamma(x))*signgam)

because not thread safe.
*/
#ifdef HAVE_TGAMMA
# define GAMMA(x) tgamma(x)
#elif defined(HAVE_GAMMA)
# define GAMMA(x) gp_gamma(x)
#elif defined(HAVE_LGAMMA_R)
static int gamma_sign;
# define GAMMA(x) (gp_exp(lgamma_r(x,&gamma_sign))*gamma_sign) /* Order of multiply important. */
#else
# define GAMMA(x) (gp_exp(lngamma(x))*sgngam) /* Order of multiply important. */
#endif

/*
Order of preference and why:

  lgamma() - It's log gamma and we don't need signgam, perfect.
  lgamma_r() - This will do if ever lgamma() is deprecated some day because of
               its non-thread-friendly, this will do.
  gamma() - There is a good chance this could be log gamma, but we use gp_lgamma()
            which has a run-time check to make sure.  If gamma() is not log gamma
	    then gp_lgamma() falls back on lngamma().
  lngamma() - Gnuplot's version of log gamma as last resort.
*/
#ifdef HAVE_LGAMMA
# define LNGAMMA(x) lgamma(x)
#elif defined(HAVE_LGAMMA_R)
static int bad_sign;  /* Born under... */
# define LNGAMMA(x) lgamma_r(x,&bad_sign)
#elif defined(HAVE_GAMMA)
# define LNGAMMA(x) gp_lgamma(x)
#else
# define LNGAMMA(x) lngamma(x)
#endif

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

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

I've put a patch on SourceForge that will use the library "true gamma" whenever gamma(x) is required, otherwise fall back on gp_gamma().  Similarly, it will use the library "natural log gamma" whenever ln(gamma(x)) is required, otherwise fall back on gp_lgamma().

It does not use of the math library's gamma() or signgam.  (Configure now only checks for tgamma and lgamma, no longer gamma or signgam.)  Hopefully, the majority of platforms will use the library tgamma() by now.

The code derives the "undefined" status from the floating point exceptions as described in the man pages.  I'm assuming that gnuplot's version of the gp_lgamma() routine sets such exceptions.  In any case, I've verified both the library and gnuplot internal versions of the gamma and lngamma functions in prob.dem.

If one wants to add a little extra to attempt to use gamma() as a last resort, this patch would make a good start.  However, I'd sort of advocate not attempting to use gamma() unless someone can convince me otherwise.

Dan

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

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I guess it doesn't pay to understand what it is beyond the fact we
>> know gamma() =3D tgamma() on your system.
>=20
>=20
> Except that we don't actually know that.  And even if we knew it, it=20
> wouldn't matter, because gnuplot doesn't use gamma() on a system that,
> like Chris', also has lgamma().  See specfun.c, line 91 ff.
>=20
> I.e. the actual bug is independent of what gamma() does on MacOS,=20
> because gnuplot isn't calling gamma().  We call lgamma(), and the bug i=
s=20
> that signgam is garbage.

Probably so.  If this is the most up-to-date documentation:

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/l=
gamma.3.html

there is no mention of a variable signgam.  So perhaps it has no meaning =
anymore for Apple's platform.  Why they would still have the variable in =
the library if that were the case, I'm not sure.

Dan

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

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

[<br...@ph...>]

Daniel J Sebald wrote:

> There may be more to this.  I see now that "signgam" is actually an
> external as part of the math library I'm guessing.  

No need for guessing --- that's what you have libc/libm manpages for.

 > So, if I
> 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?

It doesn't have to.  signgam is a global variable, exported by the 
library, and the code reads it.

> Anyway, maybe just avoiding the use of "signgam" in any way is best.

We can't do that.  Not on platforms that don't sport a tgamma(), anyway.

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

[<br...@ph...>]

Daniel J Sebald wrote:

> I guess it doesn't pay to understand what it is beyond the fact we
> know gamma() = tgamma() on your system.

Except that we don't actually know that.  And even if we knew it, it 
wouldn't matter, because gnuplot doesn't use gamma() on a system that,
like Chris', also has lgamma().  See specfun.c, line 91 ff.

I.e. the actual bug is independent of what gamma() does on MacOS, 
because gnuplot isn't calling gamma().  We call lgamma(), and the bug is 
that signgam is garbage.

Chris: please verify that in your src build directory,

     nm specfun.o | grep -i gam

prints something equivalent to this:

          U ___signgam
00000150 T _f_gamma
00000240 T _f_igamma
000001f0 T _f_lgamma
          U _lgamma

The lines with the 'U' are the important ones.  They tell us that

1) this gnuplot calls lgamma
2) gnuplot uses the library's signgam, under the name __signgam

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

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

CM wrote:
> On 9/27/06, Ethan Merritt <merritt@u.washington.edu> wrote:
> 
>>
>> On Wednesday 27 September 2006 10:21 am, Chris Monson wrote:
>> > On 9/27/06, Ethan Merritt <merritt@u.washington.edu> wrote:
>> > > On Wednesday 27 September 2006 09:43 am, Daniel J Sebald wrote:
>> > >
>> > > > I'd say this needs to be addressed before 4.2 release.
>> > >
>> > > Nah.  This is just one more oddity that an OSX packager would
>> > > have to sort out when building a binary distribution. Once the
>> > > user is up and running there is no problem at all.
>> >
>> > Is the fink distribution the proper place for this issue, then?
>>
>> I'm going to have to throw up my hands at this point.
>> I'm not a Mac person, and I don't know who/where to send such
>> a report.  From the various reports on this thread it seems that
>> the problem is present only on some Macs, or only some versions
>> of OSX, or I don't know what-all variant installed libraries.
>>
>> If somebody associated with fink, or Darwin, or some other
>> OSX developers resource can provide a definitive answer then
>> fine.  But I fear if we were to blindly 'fix' the build process
>> to work on Chris's machine, we would risk breaking it on other
>> machines.
> 
> 
> 
> Indeed.  Fortunately, what I *really* needed was lgamma (I just didn't know
> about it), so I'm currently happy with the status quo.  I would never ask
> anyone to fix something just for my machine.

Hey, you uncovered something that is definitely a problem.  The confusion seems to have worked its way into the computer community.

There may be more to this.  I see now that "signgam" is actually an external as part of the math library I'm guessing.  So, if I 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?  Anyway, maybe just avoiding the use of "signgam" in any way is best.

We could make life simple as far as configuration and code by:

1) Testing for tgamma(), if present use that as gnuplot's gamma function.  Several systems appear to have this now.

2) Fall back on the gnuplot version of gamma if tgamma() is not present.

3) Change the gnuplot code to not use the signgam/lgamma() construct.  Handle the exceptions +- Inf, NaN etc in order to set the "undefined" variable.

As an alternative, one could retain the signgam/lgamma() construct, but do not use the function "gamma()" anywhere in the code, instead only use the function "lgamma()"... if it is present of course.

Dan

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

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 27 September 2006 10:21 am, Chris Monson wrote:
> On 9/27/06, Ethan Merritt <merritt@u.washington.edu> wrote:
> > On Wednesday 27 September 2006 09:43 am, Daniel J Sebald wrote:
> >
> > > I'd say this needs to be addressed before 4.2 release.
> >
> > Nah.  This is just one more oddity that an OSX packager would
> > have to sort out when building a binary distribution. Once the
> > user is up and running there is no problem at all.
>
> Is the fink distribution the proper place for this issue, then?

I'm going to have to throw up my hands at this point.
I'm not a Mac person, and I don't know who/where to send such
a report.  From the various reports on this thread it seems that
the problem is present only on some Macs, or only some versions
of OSX, or I don't know what-all variant installed libraries.

If somebody associated with fink, or Darwin, or some other
OSX developers resource can provide a definitive answer then
fine.  But I fear if we were to blindly 'fix' the build process
to work on Chris's machine, we would risk breaking it on other
machines.  

The safest immediate solution may be to provide an entry under
"Known Problems"  somewhere in the installation docs, warning
would-be OSX packagers to check that gamma works, and tell them
to force gnuplot to use its built-in gamma function if the build
process fails to find an appropriate gamma function from the
system libraries.

Longer term, the documentation of tgamma() suggests that if it
is present at all on any system, then it can safely be used.
But I don't want to make such a change prior to 4.2

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

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

[Joe K. <jko...@co...>]

on 9/27/06 11:04 AM, Ethan Merritt at merritt@u.washington.edu wrote:

> On Wednesday 27 September 2006 09:43 am, Daniel J Sebald wrote:
>> Chris Monson wrote:
>>> Reading the posts again, it would appear that this means that
>>> sgngam is broken on my system, but that everything else
>>> (gamma-related, anyway) is working correctly.  Am I reading that
>>> right?
> 
> More or less.
> What seems to be happening is that the autoconfigure tool thinks
> that it has found a gamma function equivalent to lgamma, whereas
> on your machine "gamma" is really tgamma instead.
> We can fix that eventually.
> 
>> I'd say this needs to be addressed before 4.2 release.
> 
> Nah.  This is just one more oddity that an OSX packager would
> have to sort out when building a binary distribution. Once the
> user is up and running there is no problem at all.
> 

A thought from someone who has been hanging around just to see how this is
resolved. Has anyone filed a bug report with Apple? If there really is a
bug, or perhaps more correctly, a feature request, it should be brought to
Apple's attention. They do eventually fix such things, usually without
telling anybody.

For what it is worth, the gnuplot gamma and lgamma plot correctly on my G5
with OS X 10.4.7 and Xcode-2.4. I do have gsl-1.8 installed, and I don't
know if that affects the gamma function used.

Joe

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

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 27 September 2006 09:43 am, Daniel J Sebald wrote:
> Chris Monson wrote:
> > Reading the posts again, it would appear that this means that
> > sgngam is broken on my system, but that everything else
> > (gamma-related, anyway) is working correctly.  Am I reading that
> > right?

More or less.
What seems to be happening is that the autoconfigure tool thinks
that it has found a gamma function equivalent to lgamma, whereas
on your machine "gamma" is really tgamma instead.
We can fix that eventually.

> I'd say this needs to be addressed before 4.2 release.

Nah.  This is just one more oddity that an OSX packager would
have to sort out when building a binary distribution. Once the
user is up and running there is no problem at all.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

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

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

Chris Monson wrote:
> Reading the posts again, it would appear that this means that sgngam is
> broken on my system, but that everything else (gamma-related, anyway) is
> working correctly.  Am I reading that right?

Thanks...  Not sure; could be but maybe not.  The reason is that 

    y = GAMMA(real(pop(&a)));
[snip]
    push(Gcomplex(&a, signgam * gp_exp(y), 0.0));

doesn't make any sense anymore if GAMMA is "true" gamma rather than log gamma.  I guess it doesn't pay to understand what it is beyond the fact we know gamma() = tgamma() on your system.

I'd say this needs to be addressed before 4.2 release.

Dan

Re: gnuplot numerical errors on Intel MacBook

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

Per Persson wrote:
> On Sep 26, 2006, at 22:06, Ethan Merritt wrote:
> 
> 
>>On Tuesday 26 September 2006 12:49 pm, Per Persson wrote:
>>
>>>Hi all,
>>>sorry for being late to the party, but I've been busy buing a
>>>house...
>>
>>Congratulations!
> 
> 
> Thanks!
> 
> 
>>No, it's more complicated than that.
>>The problem is that the name "gamma" has historically been used
>>on some systems to refer to the function that is now called
>>"lgamma", and on other systems at other times to refer to a
>>function that is equivalent to "tgamma".  Thus we cannot tell
>>from the name exactly what its behaviour is.
>>
>>Gnuplot's auto-configure, as I understand it, is looking for a
>>function named "gamma" and assuming that it behaves like lgamma
>>with additional information about the sign of the result returned
>>in extern sgngam.  I am worried that on the Mac in question,
>>"gamma" is instead acting like "tgamma".  That's not broken;
>>it's just a different naming convention.  My thought was that
>>in this case we should test first for a function named "tgamma",
>>and use it along with its slightly different API.
> 
> 
> OK, if I understand things correctly, then we could
> 1) make configure check for gamma, lgamma, and tgamma *and* check  
> each of them (including tgamma to be on the safe side;-) e.g.:
> 
> AC_TRY_RUN([
> int main()
> {
>          return gamma(2.0) < 1.0;
> }
> ]
> , [ echo "gamma is GAMMA" ]
> , [ echo "gamma is LOG_OF_GAMMMA" ]
> )
> 
> to see if they are in reality $\ln\Gamma$ (LaTeX notation) and use  
> them in order:
> HAVE_LGAMMA && LGAMMA_IS_LOG_OF_GAMMA
> HAVE_GAMMA && GAMMA_IS_LOG_OF_GAMMA
> HAVE_TGAMMA && TGAMMA_IS_LOG_OF_GAMMA
> Keeping the current code in in specfunc.c (and file a bug report with  
> whoever implemented the last combo).
> 
> 2) make configure check for tgamma *and* verify that it is $\Gamma$  
> (LaTeX notation):
> HAVE_TGAMMA && !TGAMMA_IS_LOG_OF_GAMMA
> change the current code to use tgamma, and let systems without tgamma  
> rely on a fallback solution in specfunc.c
> 
> If the above is correct, then I'd support (2) but I guess it boils  
> down to how much work it would need.
> 
> /Per

Very good idea Per.  In fact, this could be carried further to run-time.  Gnuplot could have a line of code similar to the above at the start of its "main" function in the case it has to fall back on gamma().  Then have a conditional statement in specfun.c.  Is there an advantage to doing this in the case of gnuplot being compiled on a system different from where the eventual libraries are?  (Or is that pretty much made fool proof now with module i.d.s?)

Chris, identifying exactly what your gamma() routine is would be nice.  (Just replace the "tgamma()" of that patch with "gamma()" and observe the very first figure of prob.dem.)

Dan

Re: gnuplot numerical errors on Intel MacBook

[Per P. <per...@ma...>]

On Sep 26, 2006, at 22:06, Ethan Merritt wrote:

> On Tuesday 26 September 2006 12:49 pm, Per Persson wrote:
>> Hi all,
>> sorry for being late to the party, but I've been busy buing a
>> house...
>
> Congratulations!

Thanks!

>
> No, it's more complicated than that.
> The problem is that the name "gamma" has historically been used
> on some systems to refer to the function that is now called
> "lgamma", and on other systems at other times to refer to a
> function that is equivalent to "tgamma".  Thus we cannot tell
> from the name exactly what its behaviour is.
>
> Gnuplot's auto-configure, as I understand it, is looking for a
> function named "gamma" and assuming that it behaves like lgamma
> with additional information about the sign of the result returned
> in extern sgngam.  I am worried that on the Mac in question,
> "gamma" is instead acting like "tgamma".  That's not broken;
> it's just a different naming convention.  My thought was that
> in this case we should test first for a function named "tgamma",
> and use it along with its slightly different API.

OK, if I understand things correctly, then we could
1) make configure check for gamma, lgamma, and tgamma *and* check  
each of them (including tgamma to be on the safe side;-) e.g.:

AC_TRY_RUN([
int main()
{
         return gamma(2.0) < 1.0;
}
]
, [ echo "gamma is GAMMA" ]
, [ echo "gamma is LOG_OF_GAMMMA" ]
)

to see if they are in reality $\ln\Gamma$ (LaTeX notation) and use  
them in order:
HAVE_LGAMMA && LGAMMA_IS_LOG_OF_GAMMA
HAVE_GAMMA && GAMMA_IS_LOG_OF_GAMMA
HAVE_TGAMMA && TGAMMA_IS_LOG_OF_GAMMA
Keeping the current code in in specfunc.c (and file a bug report with  
whoever implemented the last combo).

2) make configure check for tgamma *and* verify that it is $\Gamma$  
(LaTeX notation):
HAVE_TGAMMA && !TGAMMA_IS_LOG_OF_GAMMA
change the current code to use tgamma, and let systems without tgamma  
rely on a fallback solution in specfunc.c

If the above is correct, then I'd support (2) but I guess it boils  
down to how much work it would need.

/Per

Re: gnuplot numerical errors on Intel MacBook

[CM <mon...@gm...>]

That's what I did, too.

I haven't had time to test the patch, yet, but will likely get to it by
tomorrow.  Hopefully sooner, but you never know.

:-)

- C

On 9/26/06, Daniel J Sebald <dan...@ie...> wrote:
>
> Per Persson wrote:
>
> > What confuses me a bit is Dan's configure run :
>
> [snip]
>
> > There is no check for tgamma on my system. Did I miss a patch or
> > something (I'm in digest mode)?
>
> No.  You didn't miss anything.  I simply added tgamma and foogamma (to
> verify the test actually can fail) to the configure.in file:
>
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>
>


-- 
:(){ :|:&};:

Re: gnuplot numerical errors on Intel MacBook

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 26 September 2006 12:49 pm, Per Persson wrote:
> Hi all,
> sorry for being late to the party, but I've been busy buing a
> house...

Congratulations!

> I don't have access to an Intel Mac, so I can't really test anything
> but checkin 'man tgamma' makes me wonder if  it would help here:
> DESCRIPTION
>       tgamma() calculates the gamma function of x.  lgamma()
> calculates the
>       natural logorithm of the absolute value of the gamma function
> of x.
>       gamma() is the same function as tgamma. Its use is deprecated.
>
> If gamma in fact *is* tgamma then tgamma is likely broken, no?

No, it's more complicated than that.
The problem is that the name "gamma" has historically been used
on some systems to refer to the function that is now called
"lgamma", and on other systems at other times to refer to a
function that is equivalent to "tgamma".  Thus we cannot tell
from the name exactly what its behaviour is.  

Gnuplot's auto-configure, as I understand it, is looking for a
function named "gamma" and assuming that it behaves like lgamma
with additional information about the sign of the result returned
in extern sgngam.  I am worried that on the Mac in question,
"gamma" is instead acting like "tgamma".  That's not broken;
it's just a different naming convention.  My thought was that
in this case we should test first for a function named "tgamma",
and use it along with its slightly different API.


> What confuses me a bit is Dan's configure run :
> There is no check for tgamma on my system.

Dan said he hacked the configure script, but I don't think
he posted a patch.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: gnuplot numerical errors on Intel MacBook

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

Per Persson wrote:

> What confuses me a bit is Dan's configure run :

[snip]
 
> There is no check for tgamma on my system. Did I miss a patch or  
> something (I'm in digest mode)?

No.  You didn't miss anything.  I simply added tgamma and foogamma (to verify the test actually can fail) to the configure.in file:

Re: gnuplot numerical errors on Intel MacBook

[Per P. <per...@ma...>]

Hi all,
sorry for being late to the party, but I've been busy buing a house...

I don't have access to an Intel Mac, so I can't really test anything  
but checkin 'man tgamma' makes me wonder if  it would help here:
DESCRIPTION
      tgamma() calculates the gamma function of x.  lgamma()  
calculates the
      natural logorithm of the absolute value of the gamma function  
of x.
      gamma() is the same function as tgamma. Its use is deprecated.

If gamma in fact *is* tgamma then tgamma is likely broken, no? Let's  
see if Dan's patch works for Chris...

What confuses me a bit is Dan's configure run :
> 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

There is no check for tgamma on my system. Did I miss a patch or  
something (I'm in digest mode)?

/Per