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

Re: Gentlemen, start your engines...

[Petr M. <mi...@ph...>]

> I have copied the same tarball to
>  http://gnuplot.sourceforge.net/development/binaries/
> since several places in the documentation and web site direct people
> to that URL.
>
> I have started to update the web pages on SourceForge as well.
> Are the mirror sites automatic, or does someone have to copy stuff
> over manually?

Web page is mirrored automatically, except for the directory
 	http://gnuplot.sourceforge.net/development/binaries/

Discussed several times, but still not fixed -- Clark? Lars? Who can let it 
working?

---
PM

place all 16 border plots on one multiplot

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

I placed a patch updating borders.dem on SourceForge as promised.  All 16 plots are on one plot.  I think it is much more useful that way, as a reference.  See below:

multiplot/x11 peculiarity

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

Not sure this is really a bug, but if you are running x11 try:

set multiplot layout 2,2
plot x
plot x
plot x
plot x
plot x
plot x
unset multiplot

(yes more than four plots) you'll see some portions of a plot at the bottom the x11 screen when the mouse sub-bar appears.

Technically gnuplot is just continuing the series, but at the end of four you might think it should stop at the fourth plot (and keep over-writing?) or maybe change back to non-multiplot mode.

Dan

Configuration bug: should not make in .../share/LaTeX/ if TeX is not present

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

On Sunday 01 October 2006 04:39 pm, Joe Koski wrote:
> 
> I'm saying the latter. LaTeX is not usually installed on Macs, and, for
> example, octave just ignores installing the octave LaTeX documentation on
> Macs. I don't think kpsexpand exists either

kpsexpand is part of TeX.

> I am always getting error messages about not finding kpsexpand

I used to get those messages too, clogging up my system log files.
I only recently learned that they were coming from gnuplot, and
tried to fix it.

It is *supposed* to be a configuration option now,
   ./configure --with-kpsexpand
    
I thought that fixed everything, but as you have found,
the .../share/LaTeX Makefile is still a problem.  

I'm not very good at this sort of build-time dependency.
Can someone fix it so that the descent into .../share/LaTeX
doesn't happen if TeX is not insalled?

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

Re: Gentlemen, start your engines...

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

Ethan A Merritt wrote:

> Already listed in NEWS
>  * NEW plot style "with points" can read variable point size from input file
>  * NEW 3D plots can read RGB color triples as part of input data

Alright.


>>* macros.dem (this one appears to fail)
> 
> 
> Works here.
> You may be confused by the message from the recursion test;
> basically it tries to recurse until it hits a limit, which triggers
> a message telling you how deep the recursion can go.

Oh.


>>* starmap.dem
> Called by datastrings.dem
>>* colorwheel.dem (doesn't seem to do anything)
> called by rainbow.dem

Demos calling subdemos, didn't think of that.


>>It would be nice to move demos that are interactive or aren't general 
>>in nature to subdirectories and have all demos that are in the base 
>>(/demo) as part of all.dem.
> 
> 
> Why?  I think it is far more logical to have all the demos in one
> place, so you don't have to go hunting around for them.

I suppose.


>>User who go to demo now and run "all.dem" will think they've seen 
>>all the demos and will not take to time to look at all the demos.
>>But with subdirectories, s/he will notice "oh there are some mouse demos"
> 
> 
> That's more of an argument for renaming "all.dem" to "check.dem"
> than it is an argument for splitting up the demos into multiple directories.

Good point.  The "all" isn't quite accurate.  Hmm... "demos.dem"?  Without saying "all" though, it looses the suggestion that it is a collection of demos.

Dan

Re: Gentlemen, start your engines...

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

On Sunday 01 October 2006 07:38 pm, Daniel J Sebald wrote:
> How about a simple statement in "new-features" about expanded key placement?
> 
> In new features, how about that "dot size and color" style?  That was after 4.1, wasn't it?
Already listed in NEWS
 * NEW plot style "with points" can read variable point size from input file
 * NEW 3D plots can read RGB color triples as part of input data

> The following demos are not in all.dem:  
> 
> * colorwheel.dem (doesn't seem to do anything)

called by rainbow.dem

> * utf8.dem
> * charset.dem

These are more debugging tools than demos per se.
They require that you set up a terminal/character set/encoding
environment before running.

> * finance.dem (pretty snazzy)

maybe

> * macros.dem (this one appears to fail)

Works here.
You may be confused by the message from the recursion test;
basically it tries to recurse until it hits a limit, which triggers
a message telling you how deep the recursion can go.

> * molecule.dem
> * mouselab_1.dem, mouselab_2.dem, mouselabels.dem, mousevariables.dem 
> (move to a subdirectory "mouse"?) 

What exactly would be the benefit?

> * starmap.dem

Called by datastrings.dem

> It would be nice to move demos that are interactive or aren't general 
> in nature to subdirectories and have all demos that are in the base 
> (/demo) as part of all.dem.

Why?  I think it is far more logical to have all the demos in one
place, so you don't have to go hunting around for them.

> User who go to demo now and run "all.dem" will think they've seen 
> all the demos and will not take to time to look at all the demos.
> But with subdirectories, s/he will notice "oh there are some mouse demos"

That's more of an argument for renaming "all.dem" to "check.dem"
than it is an argument for splitting up the demos into multiple directories.


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

Re: Gentlemen, start your engines...

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

Hans-Bernhard Br=F6ker wrote:
> Hello, everybody,
>=20
> this 4.2 release process is taking a little longer than expected.  So,=20
> based on a suggestion from Ethan, I've decided to start what the German=
=20
> proverb calls "making nails with heads".  CVS is branched (branch tag=20
> branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on=20
> both the head and the 4.2 branch).
>=20
> Everybody should check out a working copy of the branch, and test that=20
> it works as expected, on as many platforms as you can.

Works here...

I reread some documentation.  On SourceForge is a patch reflecting the fa=
ct that we changed image code so it no longer requires uniformly sampled =
data, but rather assumes it is true.

Are there any items under "new-features" that we would like to label "exp=
erimental" as we have during the config process?  Most users will not see=
 config results, just the "new-features" documentation.

How about a simple statement in "new-features" about expanded key placeme=
nt?

In new features, how about that "dot size and color" style?  That was aft=
er 4.1, wasn't it?

The following demos are not in all.dem: =20

* animate2.dem (originated for GIF animations, can be left out of all.dem=
)
* borders.dem (that one is inefficient, let me put that in the form of a =
4 x 4 multiplot)
* colorwheel.dem (doesn't seem to do anything)
* charset.dem
* dashcolor.dem (looks similar to rainbow.dem, but slightly different, pe=
rhaps it can be combined with rainbow.dem)
* epslatex.dem (shouldn't be part of all.dem, but perhaps move to subdire=
ctor "epslatex"?)
* finance.dem (pretty snazzy)
* fontfile.dem (specific to postscript, poscript subdirectory?)
* fontfile_latex.dem (subdirectory?)
* macros.dem (this one appears to fail)
* molecule.dem
* mouselab_1.dem, mouselab_2.dem, mouselabels.dem, mousevariables.dem (mo=
ve to a subdirectory "mouse"?)
* starmap.dem
* utf8.dem

It would be nice to move demos that are interactive or aren't general in =
nature to subdirectories and have all demos that are in the base (/demo) =
as part of all.dem.  (Put intendend general, but not working demos in an =
"inprogress" subdirectory or something.)  User who go to demo now and run=
 "all.dem" will think they've seen all the demos and will not take to tim=
e to look at all the demos.  But with subdirectories, s/he will notice "o=
h there are some mouse demos", for example.  Organizing like this will he=
lp developers in the future, so they don't have to ask, "What's this demo=
?", etc.

Looking forward to 4.2.

Dan


--=20

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: Gentlemen, start your engines...

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

Hans-Bernhard Br=F6ker wrote:

>>What about the Gamma problem? Is Mac hurt by it or not?
>=20
>=20
> They're obviously hurt --- the question is what is the best solution we=
=20
> can offer, and whether Apple will ever fix their end of the problem.

How can we ask someone implementing C99 to manipulate a variable "signgam=
" when the C99 standard doesn't call out such a variable?  My understandi=
ng is that C99 uses tgamma() and lgamma() and there is no need for signga=
m.

The patch I offered handles this situation.  Priority goes to tgamma() an=
d lgamma() for the GAMMA() and LNGAMMA() use in specfun.c.  If they are n=
ot present then it falls back on lgamma_r() and gamma() (ln version) for =
GAMMA() and LNGAMMA() use in specfun.c.  If those aren't present, gnuplot=
 falls back on its own version of the routines.  The patch never uses sig=
ngam because this is not thread safe.  It's a very good patch, I believe.

Dan

Re: Gentlemen, start your engines...

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

Petr Mikulik wrote:
> Good, just the following three things should go to 4.2 as well (IMHO):

... well, then you should make your changes to the branch, too.

> - the Wildcard patch

I'm not so sure about this.  This is a *very* last-minute addition, 
which has received basically no testing whatsoever.  Ethan doesn't 
consider it release-critical --- I'll leave the eventual decision to him.

> What about the Gamma problem? Is Mac hurt by it or not?

They're obviously hurt --- the question is what is the best solution we 
can offer, and whether Apple will ever fix their end of the problem.

Re: Congratulations and some Mac-related results (was Re: Gentlemen, start your engines...)

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

On Sunday 01 October 2006 04:04 pm, Joe Koski wrote:
> The only problems are apparently related to the documentation via LaTeX,
> because my installation of gnuplot-4.2 seems to be working correctly.
> 
> The final part of "make install" is as follows
> 
> <snip>
> Making install in LaTeX
> make[3]: Nothing to be done for `install-exec-am'.
> make  install-data-hook
> /bin/sh: line 1: kpsexpand: command not found
> /bin/sh: line 1: texhash: command not found

Are you saying that you have kpsexand and texhash installed,
but the build process isn't finding it?

Or are you saying that since TeX isn't installed on your system,
the build process should not bother to recurse into the LaTeX
subdirectory?

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

Congratulations and some Mac-related results (was Re: Gentlemen, start your engines...)

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

on 10/1/06 3:45 PM, Ethan A Merritt at merritt@u.washington.edu wrote:

> On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote:
>>=20
>> I'll also put up a release candidate source tarball on SF.net (in the
>> "gnuplot-current" subproject of the file release system).
>=20
> Great!
> Please join me in toasting this milestone. Your choice of beer or champag=
ne.
>=20
> I have copied the same tarball to
>   http://gnuplot.sourceforge.net/development/binaries/
> since several places in the documentation and web site direct people
> to that URL.
>=20
> I have started to update the web pages on SourceForge as well.
> Are the mirror sites automatic, or does someone have to copy stuff
> over manually?
> =20
> --=20
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742

Congratulations all around. My Mac G5 build of gnuplot-4.2 seems to be
working properly, with only a couple of minor problems (more below). This i=
s
for OS X 10.4.8 with the Xcode-2.4 developer tools.

None of the problems reported with the gamma function for the Intel Macs
surfaced on my G5 during the build. The configure script found gamma, lgamm=
a
and signgam without problems. Both gamma and lgamma plot correctly in
gnuplot-4.2.

The only problems are apparently related to the documentation via LaTeX,
because my installation of gnuplot-4.2 seems to be working correctly.

The final part of "make install" is as follows

<snip>
test -z "/Tools/gnuplot-4.2/usr/local/man/man1" || /bin/sh ../mkinstalldirs
"/Tools/gnuplot-4.2/usr/local/man/man1"
mkdir /Tools/gnuplot-4.2/usr/local/man
mkdir /Tools/gnuplot-4.2/usr/local/man/man1
 /usr/bin/install -c -m 644 './gnuplot.1'
'/Tools/gnuplot-4.2/usr/local/man/man1/gnuplot.1'
make  install-data-hook
make[3]: Nothing to be done for `install-data-hook'.
Making install in demo
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in tutorial
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Making install in share
Making install in LaTeX
make[3]: Nothing to be done for `install-exec-am'.
make  install-data-hook
/bin/sh: line 1: kpsexpand: command not found
/bin/sh: line 1: texhash: command not found
make[4]: *** [install-cfg] Error 127
make[3]: *** [install-data-am] Error 2
make[2]: *** [install-am] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
Joe-Koskis-Computer:/Tools/gnuplot-4.2.rc1 jakoski$

But as I said, the installation seems to be working. Simply bypassing the
LaTex stuff on Macs would be the easy fix. I think octave already does that=
.

Joe

Re: Gentlemen, start your engines...

[<tim...@en...>]

Hans-Bernhard Br=F6ker wrote:
> Timoth=E9e Lecomte wrote:
>
>> The patch first fixes the build of gnuplot when libpdf and gd are not=20
>> installed in standard directories. In those situations, whereas=20
>> configure was checking for the position of the gdlib-config and=20
>> pdflib-config scripts, it did not use the result !
>
> I don't think your analysis of this is correct.  GDLIB_CONFIG is=20
> searched in the same $PATH the shell will search it in.  So if=20
> AC_CHECK_PROG found it, so will the shell if you run by just=20
> "gdlib-config".
Hmm... You seem to be right. In fact, the important detail here is that=20
the user I've been discussing with has set the environment variable=20
GDLIB_CONFIG to his gdlib-config script before running 'configure'. I=20
don't really know where he found the idea to do it, but there is=20
definitely the autoconf magic to do it. It's mentioned in the help page=20
of AC_PATH_PROG, and it's called a "precious variable", as a variable=20
that can also be set by the environment, not only by a test. Maybe we=20
should declare it with AC_ARG_VAR to remove all possible ambiguity.

>
>> Moreover, there is a problem with gd on systems where GNU libiconv is=20
>> installed. In this case, gnuplot has to be linked against libiconv=20
>> too, or undefined references are obtained. The first offender here is=20
>> gdlib-config itself which doesn't report correctly '-liconv' but a=20
>> full path to libiconv.so.=20
>
> I don't think that's actually wrong.  Iconv is a massively overloaded=20
> name for a library --- it may well be one library that you *don't*=20
> want to trust the -l option to find the right copy of.

I'm not disputing the fact that there may be multiple copies, I'm=20
disputing the fact that gdlib-config reports the following, when linked=20
to GNU libiconv:

    /home/research/csmkchan/lib/libiconv.so=20
-Wl,-rpath,/home/research/csmkchan/lib/

whereas I think it should report:

    -L/home/research/csmkchan/lib -liconv -R/home/research/csmkchan/lib

(for details, gd uses LIBICONV instead of LTLIBICONV in its configure=20
script, see=20
http://www.gnu.org/software/gettext/manual/html_node/gettext_189.html
that's probably wrong since gd is precisely built as a libtool library).

>
>> script would not catch it since it doesn't take 'gdlib-config --libs'=20
>> into account. The attached patch fixes this issue too.
>
> I've learned to mistrust any obvious or easy changes to the GD=20
> configury.  Before you added wx (and all the other libs it depends=20
> on), GD was easily the single most tricky external library we ever=20
> linked against.  E.g. on some platforms, one *must* link with all the=20
> underlying libraries explicitly, on others, it's basically forbidden=20
> to try --- depending on exotica like whether a platform's shared=20
> libraries dynamically link to other shared libraries.
I agree there may be some strange things going on there...

But look carefully at the patch: as it was written before, the contents=20
of 'gdlib-config --libs' was added to TERMLIBS after the checks, so=20
gnuplot was effectively linked against all those libs. _But_ it was=20
added _after_ the checks for gdImageCreate and friends. _This_ is the=20
bug. On IRC, I checked the config.log files of "Michael" who just posted=20
to comp.graphics.apps.gnuplot under the thread "Installing 4.1", and he=20
precisely got caught by this: 'gdlib-config --libs' was asking to link=20
against libiconv, but as this wasn't added for gnuplot checks, he=20
eventually ended up with gd not found and the errors mentioned in the=20
thread.

Best regards,

Timoth=E9e Lecomte

Re: Gentlemen, start your engines...

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

On Sunday 01 October 2006 08:35 am, Hans-Bernhard Br=F6ker wrote:
>=20
> I'll also put up a release candidate source tarball on SF.net (in the=20
> "gnuplot-current" subproject of the file release system).

Great!
Please join me in toasting this milestone. Your choice of beer or champagne.

I have copied the same tarball to=20
  http://gnuplot.sourceforge.net/development/binaries/
since several places in the documentation and web site direct people
to that URL.

I have started to update the web pages on SourceForge as well.
Are the mirror sites automatic, or does someone have to copy stuff
over manually?
=20
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Gentlemen, start your engines...

[Petr M. <mi...@ph...>]

> this 4.2 release process is taking a little longer than expected.  So,
> based on a suggestion from Ethan, I've decided to start what the German
> proverb calls "making nails with heads".  CVS is branched (branch tag
> branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on
> both the head and the 4.2 branch).
>
> Everybody should check out a working copy of the branch, and test that
> it works as expected, on as many platforms as you can.

Good, just the following three things should go to 4.2 as well (IMHO):

- the Rework of configure summary patch
- the Wildcard patch

and yet another bug report I've found this weekend and passed to Ethan.

What about the Gamma problem? Is Mac hurt by it or not?


> I'll also put up a release candidate source tarball on SF.net (in the
> "gnuplot-current" subproject of the file release system).

Please wait for those fixes, and:

Some other small tasks to do:
- Some (c)/Copyright should be extended to 2006.

- Please "everybody" read the TODO file and remove all what's already in.
   -- There is a long Windows section.
   -- There is a long Lars' list.

- Could the maintainer (Clark?) organize synchronization of
 	http://www.gnuplot.info/development/binaries/
   with
 	http://gnuplot.sourceforge.net/development/binaries/

- In README.1ST, I think that sections
     Note 1 - UNISYS patent (why no more GIF images)
     Note 2 - Open source programs for PNG to GIF conversion
   can be completely removed.


---
PM

Re: Gentlemen, start your engines...

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

Timoth=E9e Lecomte wrote:

> The patch first fixes the build of gnuplot when libpdf and gd are n=
ot=20
> installed in standard directories. In those situations, whereas=
=20
> configure was checking for the position of the gdlib-config and=
=20
> pdflib-config scripts, it did not use the result !

I don't think your analysis of this is correct.  GDLIB_CONFIG is=20
searched in the same $PATH the shell will search it in.  So if=20
AC_CHECK_PROG found it, so will the shell if you run by just "gdlib-c=
onfig".

> Moreover, there is a problem with gd on systems where GNU libiconv =
is=20
> installed. In this case, gnuplot has to be linked against libiconv =
too,=20
> or undefined references are obtained. The first offender here is=
=20
> gdlib-config itself which doesn't report correctly '-liconv' but a =
full=20
> path to libiconv.so.=20

I don't think that's actually wrong.  Iconv is a massively overloaded=
=20
name for a library --- it may well be one library that you *don't* wa=
nt=20
to trust the -l option to find the right copy of.

> script would not catch it since it doesn't take 'gdlib-config --lib=
s'=20
> into account. The attached patch fixes this issue too.

I've learned to mistrust any obvious or easy changes to the GD=20
configury.  Before you added wx (and all the other libs it depends on=
),=20
GD was easily the single most tricky external library we ever linked=
=20
against.  E.g. on some platforms, one *must* link with all the=20
underlying libraries explicitly, on others, it's basically forbidden =
to=20
try --- depending on exotica like whether a platform's shared librari=
es=20
dynamically link to other shared libraries.

> Without gd fixed, LIBS=3D'-liconv' had to be used when calling 'con=
figure'.

This looks wrong. This can only really fail if libiconv was moved awa=
y=20
since its position was hard-coded into gdlib-config.  In that case, t=
he=20
GD installation has to be considered FUBAR.  It has to be reinstalled=
.

Re: Gentlemen, start your engines...

[<tim...@en...>]

Hans-Bernhard Br=F6ker wrote:
> Hello, everybody,
>
> this 4.2 release process is taking a little longer than expected.  So,=20
> based on a suggestion from Ethan, I've decided to start what the German=
=20
> proverb calls "making nails with heads".  CVS is branched (branch tag=20
> branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on=20
> both the head and the 4.2 branch).
>
> Everybody should check out a working copy of the branch, and test that=20
> it works as expected, on as many platforms as you can.
>
> I'll also put up a release candidate source tarball on SF.net (in the=20
> "gnuplot-current" subproject of the file release system).
>
> I think this candidate should be considered "beta", i.e. no publication=
=20
> of binary packages just yet, please.
>  =20

Great !

I already have a little patch to offer for a bug in the configure script.

The patch first fixes the build of gnuplot when libpdf and gd are not=20
installed in standard directories. In those situations, whereas=20
configure was checking for the position of the gdlib-config and=20
pdflib-config scripts, it did not use the result !

Moreover, there is a problem with gd on systems where GNU libiconv is=20
installed. In this case, gnuplot has to be linked against libiconv too,=20
or undefined references are obtained. The first offender here is=20
gdlib-config itself which doesn't report correctly '-liconv' but a full=20
path to libiconv.so. But even if gd gets fixed in a future release (I=20
will send the corresponding patch to M. Boutell soon), the configure=20
script would not catch it since it doesn't take 'gdlib-config --libs'=20
into account. The attached patch fixes this issue too.

With both gnuplot and gd fixed, the following are fixed :=20
http://groups.google.com.hk/group/comp.graphics.apps.gnuplot/browse_threa=
d/thread/251b6f34c427ac49/9d88d080509b83f3#9d88d080509b83f3
and probably :
http://groups.google.com.hk/group/comp.graphics.apps.gnuplot/browse_frm/t=
hread/d508bd940d3a4b6e/15014a2704cf040b?lnk=3Dgst&q=3D%22libiconv_close%2=
2&rnum=3D1#15014a2704cf040b

Without gd fixed, LIBS=3D'-liconv' had to be used when calling 'configure=
'.

May I push this bugfix patch to the 4.2 branch, or do you consider this=20
for post-4.2 ?

Best regards,

Timoth=E9e

Gentlemen, start your engines...

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

Hello, everybody,

this 4.2 release process is taking a little longer than expected.  So, 
based on a suggestion from Ethan, I've decided to start what the German 
proverb calls "making nails with heads".  CVS is branched (branch tag 
branch-4-2-stable), VERSION is 4.2 and PATCHLEVEL is rc1 (for now on 
both the head and the 4.2 branch).

Everybody should check out a working copy of the branch, and test that 
it works as expected, on as many platforms as you can.

I'll also put up a release candidate source tarball on SF.net (in the 
"gnuplot-current" subproject of the file release system).

I think this candidate should be considered "beta", i.e. no publication 
of binary packages just yet, please.

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

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

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.

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

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

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.

Re: gnuplot numerical errors on Intel MacBook

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

Ethan Merritt wrote:

>>COuld you please give me a link for that?  I'm looking at a draft
>>document of
>>
>>http://www.open-std.org/JTC1/SC22/WG14/www/standards
> 
> 
> The rationale doc that I quoted is indeed indexed on that page.

Oh yeah, right in front of my nose.  Well, the doc uses "Single Unix" a couple times but doesn't define it.

Maybe submitting a bug report is best.  But be sure to mention lgamma() has been discussed by a group and interpretation of its exact behavior left unresolved.

Dan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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