Menu
▾
▴
gnuplot-beta
|
From: CM <mon...@gm...> - 2006-09-23 23:00:27
|
Has anyone seen numerical errors on the MacBook line of computers? I have tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package), and in each case the result of plot gamma(x) is very, very wrong. Has anyone else seen this? I searched the archives for this list and didn't see anything relevant. - C |
|
From: <br...@ph...> - 2006-09-23 23:15:04
|
CM wrote: > Has anyone seen numerical errors on the MacBook line of computers? I > have tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac > package), Compiled for which target / terminal drivers? Aqua, X11, or wx? All three of them? > and in each case the result of > > plot gamma(x) > > is very, very wrong. Has anyone else seen this? That's quite completely impossible to answer --- how can we know if we saw this, if you don't tell tell us what it is we're supposed to see? |
|
From: Dmitri A. S. <das...@gm...> - 2006-09-23 23:56:32
|
On 9/23/06, CM <mon...@gm...> wrote: > Has anyone seen numerical errors on the MacBook line of computers? I have > tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package), > and in each case the result of > > plot gamma(x) > > is very, very wrong. Has anyone else seen this? I searched the archives > for this list and didn't see anything relevant. Does it look better if you do: gnuplot> set samples 100000 gnuplot> plot [-2.5:6][-100:100] gamma(x) ? > > - C > Sincerely, Dmitri. -- |
|
From: Joe K. <jko...@co...> - 2006-09-24 00:57:49
|
on 9/23/06 5:56 PM, Dmitri A. Sergatskov at das...@gm... wrote: > On 9/23/06, CM <mon...@gm...> wrote: >> Has anyone seen numerical errors on the MacBook line of computers? I have >> tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package), >> and in each case the result of >> >> plot gamma(x) >> >> is very, very wrong. Has anyone else seen this? I searched the archives >> for this list and didn't see anything relevant. > > Does it look better if you do: > > gnuplot> set samples 100000 > gnuplot> plot [-2.5:6][-100:100] gamma(x) > > ? > >> >> - C >> > > Sincerely, > > Dmitri. > -- > For what it is worth, my gnuplot-4.1 compiled from CVS March 17, 2006 had severe problems with pm3d colors. My latest CVS, Sept. 17, 2006 gives correct pm3d colors and compares well with gnuplot-4.0. Is it a version issue? Did you compile your gnuplot-4.1 from the (now stale) March snapshot? Joe |
|
From: Daniel J S. <dan...@ie...> - 2006-09-24 01:28:04
|
CM wrote: > Has anyone seen numerical errors on the MacBook line of computers? I have > tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package), > and in each case the result of > > plot gamma(x) > > is very, very wrong. Has anyone else seen this? I searched the archives > for this list and didn't see anything relevant. > > - C As Hans said, please give us some results we can verify against. However, I think that the gamma function is working properly, as I had just spruced up the 'prob.dem' file. Please have a look at that file. I added some printouts of the gamma function and the log gamma function, and spent a lot of time making sure I got adequate sampling in those tricky subregions to the left of the plot. I will send you some screen captures separately. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-24 03:30:07
|
On Saturday 23 September 2006 07:46 pm, CM wrote: > I'm sorry. I should have provided more information. >=20 > Version of GNUPlot: >=20 > 4.0 (from fink on Tiger, MacBook Pro) > 4.1 (from cvs today, same platform) >=20 > gamma(x) is returning all negative values, and very, very large ones at > that. Could you please check for compiler warnings or errors during the build. In particular, look to see if any variant of the gamma function is mentioned in connection with a message on the order of "implicit declaration of built-in function =E2=80=98lgamma=E2=80= =99". But please report all warnings or errors. Also please look in the file config.h created while preparing the cvs distribution and tell us whether HAVE_LGAMMA is defined or commented out. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: CM <mon...@gm...> - 2006-09-24 06:12:55
|
On 9/23/06, Ethan A Merritt <merritt@u.washington.edu> wrote: > > On Saturday 23 September 2006 07:46 pm, CM wrote: > > I'm sorry. I should have provided more information. > > > > Version of GNUPlot: > > > > 4.0 (from fink on Tiger, MacBook Pro) > > 4.1 (from cvs today, same platform) > > > > gamma(x) is returning all negative values, and very, very large ones at > > that. > > Could you please check for compiler warnings or errors during the > build. In particular, look to see if any variant of the > gamma function is mentioned in connection with a message on the > order of "implicit declaration of built-in function 'lgamma'". > But please report all warnings or errors. Here is all of the stderr output (minus the last obvious stuff) that might be relevant, but appears not to be anyway: set.c: In function 'set_mouse': set.c:2309: warning: pointer targets in passing argument 2 of 'map_position' differ in signedness set.c:2309: warning: pointer targets in passing argument 3 of 'map_position' differ in signedness /usr/bin/ld: warning multiple definitions of symbol _init_color color.o definition of _init_color in section (__TEXT,__text) /sw/lib/libncurses.dylib(lib_color.o) definition of _init_color /usr/bin/ld: warning multiple definitions of symbol _set_term term.o definition of _set_term in section (__TEXT,__text) /sw/lib/libncurses.dylib(lib_set_term.o) definition of _set_term Also please look in the file config.h created while preparing > the cvs distribution and tell us whether HAVE_LGAMMA is defined or > commented out. HAVE_LGAMMA is defined to be 1, not commented out. The config output indicates that both "gamma" and "lgamma" are found, but the log says this: configure:8466: checking for gamma configure:8522: gcc -o conftest -g -O2 -I/usr/X11R6/include conftest.c >&5 conftest.c:94: warning: conflicting types for built-in function 'gamma' configure:8528: $? = 0 configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err configure:8538: $? = 0 configure:8545: test -s conftest configure:8548: $? = 0 configure:8562: result: yes configure:8466: checking for lgamma configure:8522: gcc -o conftest -g -O2 -I/usr/X11R6/include conftest.c >&5 conftest.c:95: warning: conflicting types for built-in function 'lgamma' configure:8528: $? = 0 configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err configure:8538: $? = 0 configure:8545: test -s conftest configure:8548: $? = 0 configure:8562: result: yes In other words, it finds them, but gets some interesting warnings. - C |
|
From: Daniel J S. <dan...@ie...> - 2006-09-24 06:30:46
|
CM wrote: > The config output indicates that both "gamma" and "lgamma" are found, but > the log says this: > > configure:8466: checking for gamma > configure:8522: gcc -o conftest -g -O2 -I/usr/X11R6/include conftest.c > >> &5 > > conftest.c:94: warning: conflicting types for built-in function 'gamma' > configure:8528: $? = 0 > configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err > configure:8538: $? = 0 > configure:8545: test -s conftest > configure:8548: $? = 0 > configure:8562: result: yes > configure:8466: checking for lgamma > configure:8522: gcc -o conftest -g -O2 -I/usr/X11R6/include conftest.c > >> &5 > > conftest.c:95: warning: conflicting types for built-in function 'lgamma' > configure:8528: $? = 0 > configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err > configure:8538: $? = 0 > configure:8545: test -s conftest > configure:8548: $? = 0 > configure:8562: result: yes > > In other words, it finds them, but gets some interesting warnings. I get those too in the configuration file. (Never noticed.) However, everything seems fine to me. I see similar warnings for several functions like sin() and efc(). Are those routines working for you? "plot sin(x)", or try the 'bivariat.dem' demo... Dan |
|
From: CM <mon...@gm...> - 2006-09-24 06:37:03
|
On 9/23/06, Daniel J Sebald <dan...@ie...> wrote:
>
> CM wrote:
> > The config output indicates that both "gamma" and "lgamma" are found,
> but
> > the log says this:
> >
> > configure:8466: checking for gamma
> > configure:8522: gcc -o conftest -g -O2 -I/usr/X11R6/include
> conftest.c
> >
> >> &5
> >
> > conftest.c:94: warning: conflicting types for built-in function 'gamma'
> > configure:8528: $? = 0
> > configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> > configure:8538: $? = 0
> > configure:8545: test -s conftest
> > configure:8548: $? = 0
> > configure:8562: result: yes
> > configure:8466: checking for lgamma
> > configure:8522: gcc -o conftest -g -O2 -I/usr/X11R6/include
> conftest.c
> >
> >> &5
> >
> > conftest.c:95: warning: conflicting types for built-in function 'lgamma'
> > configure:8528: $? = 0
> > configure:8535: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> > configure:8538: $? = 0
> > configure:8545: test -s conftest
> > configure:8548: $? = 0
> > configure:8562: result: yes
> >
> > In other words, it finds them, but gets some interesting warnings.
>
> I get those too in the configuration file. (Never noticed.) However,
> everything seems fine to me. I see similar warnings for several functions
> like sin() and efc().
>
> Are those routines working for you? "plot sin(x)", or try the '
> bivariat.dem' demo...
Yes, sin and bivariat.dem both work correctly.
Dan
>
--
:(){ :|:&};:
|
|
From: Daniel J S. <dan...@ie...> - 2006-09-24 08:43:30
|
CM wrote: >> I get those too in the configuration file. (Never noticed.) However, >> everything seems fine to me. I see similar warnings for several >> functions >> like sin() and efc(). >> >> Are those routines working for you? "plot sin(x)", or try the ' >> bivariat.dem' demo... > > > > Yes, sin and bivariat.dem both work correctly. Hmm, that would suggest to me a problem with the exterior gamma function. (We should get rid of these warnings though as a first step.) Hans? Ethan? Any ideas? Dan |
|
From: <br...@ph...> - 2006-09-24 12:36:18
|
Daniel J Sebald wrote: > Hmm, that would suggest to me a problem with the exterior gamma > function. (We should get rid of these warnings though as a first > step.) No. Those warnings are harmless --- they occur for basically all functions tested by ./configure that turn out to be GCC built-in functions. The most likely reason for this problem is signgam, the extra variable used by gamma() to report the sign of its result (since the main result is the logarithmized gamma value, it can't carry the sign). This is quite notorious for being absent; or present but not declared in any header. In case of doubt, you may have to use autoconf's mechanisms for forcing the results of the gamma() and lgamma() tests to "no" (or edit config.h before running 'make'). |
|
From: Daniel J S. <dan...@ie...> - 2006-09-24 16:21:32
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >=20 >>Hmm, that would suggest to me a problem with the exterior gamma >>function. (We should get rid of these warnings though as a first >>step.) =20 >=20 >=20 > No. Those warnings are harmless --- they occur for basically all > functions tested by ./configure that turn out to be GCC built-in functi= ons. >=20 > The most likely reason for this problem is signgam, the extra variable=20 > used by gamma() to report the sign of its result (since the main result= =20 > is the logarithmized gamma value, it can't carry the sign). This is=20 > quite notorious for being absent; or present but not declared in any he= ader. >=20 > In case of doubt, you may have to use autoconf's mechanisms for forcing > the results of the gamma() and lgamma() tests to "no" (or edit config.h= =20 > before running 'make'). Then if C runs the 'prob.dem' demo, it should be inverted. (Is that what= you are seeing for that demo?) Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-24 20:52:59
|
On Saturday 23 September 2006 11:12 pm, CM wrote: > Also please look in the file config.h created while preparing > > the cvs distribution and tell us whether HAVE_LGAMMA is defined or > > commented out. > > HAVE_LGAMMA is defined to be 1, not commented out. Hmm. Well, you can probably get a working gamma function by replacing this line with #undef HAVE_LGAMMA #undef HAVE_GAMMA and then rebuilding the program. (Do not re-run ./configure) Unfortunately, that won't help us figure out what is going wrong with the normal configure+build process. I've CC'ed this to Per Persson, who is our Mac expert. This is a PPC MacBook? > Has anyone seen numerical errors on the MacBook line of computers? I have > tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac package), > and in each case the result of > plot gamma(x) > is very, very wrong. Has anyone else seen this? I searched the archives > for this list and didn't see anything relevant. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: CM <mon...@gm...> - 2006-09-24 21:16:57
|
On 9/24/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
>
> On Saturday 23 September 2006 11:12 pm, CM wrote:
> > Also please look in the file config.h created while preparing
> > > the cvs distribution and tell us whether HAVE_LGAMMA is defined or
> > > commented out.
> >
> > HAVE_LGAMMA is defined to be 1, not commented out.
>
> Hmm. Well, you can probably get a working gamma function by
> replacing this line with
> #undef HAVE_LGAMMA
> #undef HAVE_GAMMA
> and then rebuilding the program. (Do not re-run ./configure)
Yay! It *mostly* works, now. It seems to be plotting the right function,
but emits the error message:
lngamma singularity error
Unfortunately, that won't help us figure out what is
> going wrong with the normal configure+build process.
>
> I've CC'ed this to Per Persson, who is our Mac expert.
> This is a PPC MacBook?
No, it's an Intel machine. (As far as I know, it is universally true that
PowerBook == PPC and MacBook == Intel).
Let me know what I can do to help.
> Has anyone seen numerical errors on the MacBook line of computers? I have
> > tried both gnuplot 4.0 and 4.1 (compiled from source, not the mac
> package),
> > and in each case the result of
>
> > plot gamma(x)
>
> > is very, very wrong. Has anyone else seen this? I searched the
> archives
> > for this list and didn't see anything relevant.
>
>
>
> --
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
>
--
:(){ :|:&};:
|
|
From: Per P. <per...@ma...> - 2006-09-26 19:49:57
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-09-26 20:07:01
|
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 |
|
From: Per P. <per...@ma...> - 2006-09-26 22:27:41
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2006-09-27 06:05:36
|
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
|
|
From: <br...@ph...> - 2006-09-24 21:17:29
|
CM wrote:
> No, that's not what I'm seeing. I'm seeing a graph with dotted lines
> but no function output. I have posted one more picture, this time the
> result of running
>
> plot [1:2] gamma(x)
>
> It's rather interesting, and I'm afraid not terribly enlightening.
Actually, it is. It matches my original guess perfectly. It shows
exactly what you would get if signgam is random garbage, which just so
happens to equal -5.58e8. This is because the implementation of the
user-visible function gamma() is internally:
double gamma(gamma x) {
return exp(GAMMA(x)) * signgam;
}
[see specfun.c:f_gamma()], where GAMMA is either lgamma(), gamma(), or
gnuplot's own lngamma(), depending on availability. The correct values
of gamma(1) and gamma(2) are 1.0, yours are -5.58e08, but other than
that, the shape is quite right. I get exactly your plot, but for
plot [1:2] -5.58e8*gamma(x)
Please check your config.log's lines about signgam.
The true test would be that while gamma() is wrong, lgamma() plots
correctly.
|
|
From: CM <mon...@gm...> - 2006-09-24 21:48:34
|
On 9/24/06, Hans-Bernhard Br=F6ker <br...@ph...> wrote:
>
> CM wrote:
>
> > No, that's not what I'm seeing. I'm seeing a graph with dotted lines
> > but no function output. I have posted one more picture, this time the
> > result of running
> >
> > plot [1:2] gamma(x)
> >
> > It's rather interesting, and I'm afraid not terribly enlightening.
>
> Actually, it is. It matches my original guess perfectly. It shows
> exactly what you would get if signgam is random garbage, which just so
> happens to equal -5.58e8. This is because the implementation of the
> user-visible function gamma() is internally:
>
> double gamma(gamma x) {
> return exp(GAMMA(x)) * signgam;
> }
>
> [see specfun.c:f_gamma()], where GAMMA is either lgamma(), gamma(), or
> gnuplot's own lngamma(), depending on availability. The correct values
> of gamma(1) and gamma(2) are 1.0, yours are -5.58e08, but other than
> that, the shape is quite right. I get exactly your plot, but for
>
> plot [1:2] -5.58e8*gamma(x)
>
> Please check your config.log's lines about signgam.
configure:8573: checking whether signgam is declared
configure:8607: gcc -c -g -O2 -I/usr/X11R6/include conftest.c >&5
configure:8613: $? =3D 0
configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err
configure:8623: $? =3D 0
configure:8630: test -s conftest.o
configure:8633: $? =3D 0
configure:8645: result: yes
Is this what you expected?
The true test would be that while gamma() is wrong, lgamma() plots
> correctly.
Aha. Yes. lgamma does, in fact, do the right thing.
- C
|
|
From: <br...@ph...> - 2006-09-24 23:21:03
|
CM wrote: > configure:8573: checking whether signgam is declared > configure:8607: gcc -c -g -O2 -I/usr/X11R6/include conftest.c >&5 > configure:8613: $? = 0 > configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err > configure:8623: $? = 0 > configure:8630: test -s conftest.o > configure:8633: $? = 0 > configure:8645: result: yes > > Is this what you expected? Not really. What this set of observations means is that the signgam aspect of the gamma() implementation on Intel Macs is rather interestingly broken. That's about as far as gnuplot's end of the problem can be traced. For the rest you'll have to bring this to the attention of Mac experts, or maybe Apple themselves. It might be some unwanted side effect of someone's try to make gamma() thread-safe. |
|
From: Joe K. <jko...@co...> - 2006-09-25 01:20:01
|
on 9/24/06 5:23 PM, Hans-Bernhard Br=F6ker at br...@ph... wrote: > CM wrote: >=20 >> configure:8573: checking whether signgam is declared >> configure:8607: gcc -c -g -O2 -I/usr/X11R6/include conftest.c >&5 >> configure:8613: $? =3D 0 >> configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err >> configure:8623: $? =3D 0 >> configure:8630: test -s conftest.o >> configure:8633: $? =3D 0 >> configure:8645: result: yes >>=20 >> Is this what you expected? >=20 > Not really. What this set of observations means is that the signgam > aspect of the gamma() implementation on Intel Macs is rather > interestingly broken. That's about as far as gnuplot's end of the > problem can be traced. For the rest you'll have to bring this to the > attention of Mac experts, or maybe Apple themselves. It might be some > unwanted side effect of someone's try to make gamma() thread-safe. >=20 My total knowledge of this subject consists of owning a copy of Abramowitz and Stegun, so please excuse me it the following is a red herring. On his daily blog on the g95 website, g95.sourceforge.net, Andy Vaught wrot= e =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D September 6 Bill McKie pointed out that x86/OSX wasn't trapping overflows during real exponentiation. It turns out that OSX uses the MMX unit to do exponentiatio= n instead of the x87. So I added code to set the bits for MMX traps. Not only does the MMX exponentiation use about six times the code that the x87 uses, but it turns out that OSX doesn't handle traps from the MMX unit correctly either, reporting only a generic floating point exception. To add insult to injury, it takes about 3/4 of second (!) to process a floating point exception on OSX, be it x86 or powerpc. September 13 The origin of this problem was detecting overflow during exponentiation on OSX/386, which uses the SSE unit to do the math. I ran a speed test comparing exponentiation using the SSE unit with x87, and the x87 is 25% faster, and delivers a more accurate result because the intermediate quantities are carried to 64 bits in the mantissa. So the solution is not t= o bend over backwards for the SSE unit, but rather use the x87 for exponentiation where it is available. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So the Intel Mac does math somewhat differently than its Windows cousins. This may or may not be relevant here, but I just thought I'd point it out. Joe |
|
From: Daniel J S. <dan...@ie...> - 2006-09-25 01:48:03
|
Joe Koski wrote: > My total knowledge of this subject consists of owning a copy of Abramowitz > and Stegun, so please excuse me it the following is a red herring. > > On his daily blog on the g95 website, g95.sourceforge.net, Andy Vaught wrote > ===================== > September 6 > Bill McKie pointed out that x86/OSX wasn't trapping overflows during real > exponentiation. It turns out that OSX uses the MMX unit to do exponentiation > instead of the x87. So I added code to set the bits for MMX traps. Not only > does the MMX exponentiation use about six times the code that the x87 uses, > but it turns out that OSX doesn't handle traps from the MMX unit correctly > either, reporting only a generic floating point exception. To add insult to > injury, it takes about 3/4 of second (!) to process a floating point > exception on OSX, be it x86 or powerpc. > > September 13 > The origin of this problem was detecting overflow during exponentiation on > OSX/386, which uses the SSE unit to do the math. I ran a speed test > comparing exponentiation using the SSE unit with x87, and the x87 is 25% > faster, and delivers a more accurate result because the intermediate > quantities are carried to 64 bits in the mantissa. So the solution is not to > bend over backwards for the SSE unit, but rather use the x87 for > exponentiation where it is available. > ===================== Wonder why they would choose that? The extra instructions to set up the MMX registers only pays off, I think, when one actually uses the multiple registers. For a single computation, the more general and common approach would be better... They aren't expecting an MMX version of gnuplot, I hope. ;-) Dan |
|
From: CM <mon...@gm...> - 2006-09-24 23:30:59
|
I suppose this means that the next question from gnuplot's side of things i=
s
"Should we fiddle with auto configuration to work around this?"
On 9/24/06, Hans-Bernhard Br=F6ker <br...@ph...> wrote:
>
> CM wrote:
>
> > configure:8573: checking whether signgam is declared
> > configure:8607: gcc -c -g -O2 -I/usr/X11R6/include conftest.c >&5
> > configure:8613: $? =3D 0
> > configure:8620: test -z "$ac_c_werror_flag" || test ! -s conftest.err
> > configure:8623: $? =3D 0
> > configure:8630: test -s conftest.o
> > configure:8633: $? =3D 0
> > configure:8645: result: yes
> >
> > Is this what you expected?
>
> Not really. What this set of observations means is that the signgam
> aspect of the gamma() implementation on Intel Macs is rather
> interestingly broken. That's about as far as gnuplot's end of the
> problem can be traced. For the rest you'll have to bring this to the
> attention of Mac experts, or maybe Apple themselves. It might be some
> unwanted side effect of someone's try to make gamma() thread-safe.
>
>
>
>
--=20
:(){ :|:&};:
|
|
From: <br...@ph...> - 2006-09-25 20:06:02
|
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. |
