* autoconf usage : -DHAVE_GSL ? @ 2001-12-19 13:20 Peter Teuben 2001-12-19 13:20 ` Brian Gough ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Peter Teuben @ 2001-12-19 13:20 UTC (permalink / raw) To: gsl-discuss I'd like to have a macro HAVE_GSL, so i can #ifdef my code. I followed some of the instructions in section 2.4 on automake, and added the gsl.m4 to my aclocal.m4 and did something like the following in configure.in : AM_PATH_GSL(0.9.2, ok=yes, ok=no) if test "$ok" = "yes"; then AC_MSG_RESULT(ok, i found GSL) NEMO_CFLAGS="$NEMO_CFLAGS $GSL_CFLAGS -DHAVE_GSL" NEMO_LIBS="$NEMO_LIBS $GSL_LIBS" else AC_MSG_WARN(could not find GSL library) fi My question is about the kludgie looking -DHAVE_GSL. I wanted to use something like AC_CHECK_LIB(gsl,gsl_version) but that fails, gsl_version seems to needs -lgslcblas! (which is actually odd, if I look at the output of nm..... -static will fix that dependancy, but AC_CHECK_LIB does not do that) I'd like to know which function/static would be the one that doesn't need another library. Can that be done with AC_CHECK_LIB? If so, perhaps this should be added to section 2.4 on the automake macros. Or perhaps is there a better way to get the HAVE_GSL macro? - peter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 autoconf usage : -DHAVE_GSL ? Peter Teuben @ 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` gsl-discuss 2001-12-19 13:20 ` autoconf usage : -DHAVE_GSL ? gsl-discuss 2001-12-19 13:20 ` gsl_poly_eval Peter Teuben 2 siblings, 1 reply; 14+ messages in thread From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw) To: Peter Teuben; +Cc: gsl-discuss Peter Teuben writes: > My question is about the kludgie looking -DHAVE_GSL. I wanted to > use something like > AC_CHECK_LIB(gsl,gsl_version) > but that fails, gsl_version seems to needs -lgslcblas! (which is > actually odd, if I look at the output of nm..... -static will fix > that dependancy, but AC_CHECK_LIB does not do that) I'd like to > know which function/static would be the one that doesn't need > another library. Function 'main' -- standard autoconf trick. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 ` Brian Gough @ 2001-12-19 13:20 ` gsl-discuss 2001-12-19 13:20 ` Peter Teuben 0 siblings, 1 reply; 14+ messages in thread From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw) To: gsl-discuss; +Cc: Peter Teuben On Sat, Sep 08, 2001 at 10:47:43AM +0100, Brian Gough wrote: > Peter Teuben writes: > > My question is about the kludgie looking -DHAVE_GSL. I wanted to > > use something like > > AC_CHECK_LIB(gsl,gsl_version) > > but that fails, gsl_version seems to needs -lgslcblas! (which is > > actually odd, if I look at the output of nm..... -static will fix > > that dependancy, but AC_CHECK_LIB does not do that) I'd like to > > know which function/static would be the one that doesn't need > > another library. > > Function 'main' -- standard autoconf trick. Actually, I'd term it a "misuse". The fact that the library exists doesn't mean you should link against it. You should first AC_TRY_FUNC because it might already be in $LIBS. -- albert chin (china@thewrittenword.com) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 ` gsl-discuss @ 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) Peter Teuben 0 siblings, 2 replies; 14+ messages in thread From: Peter Teuben @ 2001-12-19 13:20 UTC (permalink / raw) To: gsl-discuss > > Function 'main' -- standard autoconf trick. > > Actually, I'd term it a "misuse". The fact that the library exists > doesn't mean you should link against it. You should first AC_TRY_FUNC > because it might already be in $LIBS. actually, this still didn't work for me ! It still claimed it would not even find main. If i link static (manually done), things look better, but basically, i kept the stupid kludge in until i find something that actually works. - peter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 ` Peter Teuben @ 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` J.J. Gomez Cadenas 2001-12-19 13:20 ` fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) Peter Teuben 1 sibling, 1 reply; 14+ messages in thread From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw) To: Peter Teuben; +Cc: gsl-discuss Peter Teuben writes: > actually, this still didn't work for me ! It still claimed it > would not even find main. If i link static (manually done), things > look better, but basically, i kept the stupid kludge in until i > find something that actually works. how about, AC_SEARCH_LIBS(sin, m); AC_SEARCH_LIBS(cblas_daxpy,gslcblas) AC_SEARCH_LIBS(gsl_version,gsl) ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 ` Brian Gough @ 2001-12-19 13:20 ` J.J. Gomez Cadenas 2001-12-19 13:20 ` Brian Gough 0 siblings, 1 reply; 14+ messages in thread From: J.J. Gomez Cadenas @ 2001-12-19 13:20 UTC (permalink / raw) To: Brian Gough; +Cc: gsl-discuss Dear Brian, For the wrapper classes that I am preparing (so far, complex, permutations, vector & matrices) I would like to have the last version of GSL with your last additions (LU and LU inverse for a complex matrix, etc). I am working chiefly in Windows, this days. Would it be possible for you to create another setup.exe with an updated version, some time? Concerning matrices. There is a typo in the documentation, pag 84, it should say gsl_matrix_mul_element (and gsl_matrix_div_element) instead of gsl_matrix_mul, which is very misleading (unless you read carefully the title makes you believe it's the product of two matrices not the product of the elements). Actually, you do not include the product of two matrices as matrix operation but in linear algebra. Why? The product of two matrices is guaranteed to exist, e.g, the matrix are a ring, so the operation is well defined. In the same grounds that you include the addition of two matrices (matrices are a group) I would tend to add the product. Best, jj -----Mensaje original----- De: gsl-discuss-owner@sources.redhat.com [ mailto:gsl-discuss-owner@sources.redhat.com]En nombre de Brian Gough Enviado el: domingo, 09 de septiembre de 2001 11:37 Para: Peter Teuben CC: gsl-discuss@sourceware.cygnus.com Asunto: Re: autoconf usage : -DHAVE_GSL ? Peter Teuben writes: > actually, this still didn't work for me ! It still claimed it > would not even find main. If i link static (manually done), things > look better, but basically, i kept the stupid kludge in until i > find something that actually works. how about, AC_SEARCH_LIBS(sin, m); AC_SEARCH_LIBS(cblas_daxpy,gslcblas) AC_SEARCH_LIBS(gsl_version,gsl) ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 ` J.J. Gomez Cadenas @ 2001-12-19 13:20 ` Brian Gough 0 siblings, 0 replies; 14+ messages in thread From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw) To: J.J. Gomez Cadenas; +Cc: gsl-discuss J.J. Gomez Cadenas writes: > For the wrapper classes that I am preparing (so far, complex, permutations, > vector & matrices) I would like to have the last version of GSL with your > last additions (LU and LU inverse for a complex matrix, etc). I am working > chiefly in Windows, this days. Would it be possible for you to create > another setup.exe with an updated version, some time? Ok. I'll make one tomorrow. Currently there's one on my webpage which has 'inline' functions working, but doesn't have the complex LU. I haven't benchmarked it yet. In principle it should give improved performance for some of the linear algebra. The file size is much larger though. > Concerning matrices. There is a typo in the documentation, pag 84, it should > say gsl_matrix_mul_element (and gsl_matrix_div_element) instead of > gsl_matrix_mul, which is very misleading (unless you read carefully the > title makes you believe it's the product of two matrices not the product of > the elements). Thanks, now corrected. > Actually, you do not include the product of two matrices as matrix operation > but in linear algebra. Why? The product of two matrices is guaranteed to > exist, e.g, the matrix are a ring, so the operation is well defined. In the > same grounds that you include the addition of two matrices (matrices are a > group) I would tend to add the product. I left out the matrix multiply because it is in BLAS, but matrix addition is not so I provided that separately. Strictly speaking the 'matmul' function in linalg is also obsolete. At that time the blas library was not finished so the matmul function was used. Now that the BLAS is complete I recommend using gsl_blas_dgemm for better performance. This doesn't cover multiplying of integer matrices, but it would seem to be dangerous to multiply those as they could easily overflow. ^ permalink raw reply [flat|nested] 14+ messages in thread
* fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` Brian Gough @ 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` Brian Gough 1 sibling, 1 reply; 14+ messages in thread From: Peter Teuben @ 2001-12-19 13:20 UTC (permalink / raw) To: gsl-discuss A philosphical question: I have been using a few gsl routine and replacing some of my own old codes. I like gsl, i certainly like to see more! But one thing that I found a bit of a nuisance is that there is sometimes some surprising fprintf(stderr,.....) calls in some routines. Actually, I only ran into one so far, the RNG setup routine, gsl_rng_env_setup. I happen to prefer to pass parameters via functions, not via environment variables, but that can be solved with putenv(), which is what i had to do. But this results in output like GSL_RNG_TYPE=ran3 GSL_RNG_SEED=10880933 and now my scripts that do a lof of simulations and set the rng via the system clock [using times()], so i now suddenly get a lot of lines of output! In the above case, the user can always use gsl_rng_default_seed, and gsl_rng_name(), as shown in the example in Section 16.6, so I wondered why this output was needed at all. They occur in fairly low level routines, and potentially can interfer with client software, without the client having a chance to silence it more. What we did in our own software was to define a global debug level (via the DEBUG environment variable or via a set_debug_level() function) and all fprintf(stderr,....) was replaced with dprintf(req_level,.....). So, if the user did nothing, it became equivalent to an fprintf(stderr,...), else it was never shown unless debug=1 or debug=2 was used. btw, dprintf() is now a bad name, it appears to have been hijacked by gnu/libc? judging from newer /usr/include/stdio.h files. - peter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) 2001-12-19 13:20 ` fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) Peter Teuben @ 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` Peter Teuben 0 siblings, 1 reply; 14+ messages in thread From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw) To: Peter Teuben; +Cc: gsl-discuss Peter Teuben writes: > A philosphical question: I have been using a few gsl routine and > replacing some of my own old codes. I like gsl, i certainly like to > see more! But one thing that I found a bit of a nuisance is that > there is sometimes some surprising fprintf(stderr,.....) calls in > some routines. Actually, I only ran into one so far, the RNG setup > routine, gsl_rng_env_setup. > I happen to prefer to pass parameters via functions, not via > environment variables, but that can be solved with putenv(), which The environment variables are completely optional -- they are only used if you explicitly call gsl_rng_env_setup(). You can set the parameters by direct assignment in C. e.g. #include <gsl/gsl_rng.h> int main () { .... gsl_rng_default_seed = 123; gsl_rng_default_type = gsl_rng_ran3 ; regards Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) 2001-12-19 13:20 ` Brian Gough @ 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` Brian Gough 0 siblings, 1 reply; 14+ messages in thread From: Peter Teuben @ 2001-12-19 13:20 UTC (permalink / raw) To: Brian Gough; +Cc: gsl-discuss > The environment variables are completely optional -- they are only > used if you explicitly call gsl_rng_env_setup(). You can set the > parameters by direct assignment in C. e.g. > > #include <gsl/gsl_rng.h> > > int main () { > .... > gsl_rng_default_seed = 123; > gsl_rng_default_type = gsl_rng_ran3 ; > yes, I understood that also from the example, but i actually like the idea of the user giving control of the random number generator. So in the code the user can supply seed=0,ran3 where they are both optional. The method of assigning to gsl_rng_default_type would require me to manually build a large list of (to me officially unknown) names, whereas the putenv() method has the nice side-effect that if you say seed=0,help you get ... Valid generator types are: cmrg gfsr4 minstd mrg mt19937 r250 ran0 ran1 ran2 ran3 rand48 rand random128-bsd random128-glibc2 random128-libc5 random256-bsd random256-glibc2 random256-libc5 random32-bsd random32-glibc2 random32-libc5 random64-bsd random64-glibc2 random64-libc5 random8-bsd random8-glibc2 random8-libc5 random-bsd random-glibc2 random-libc5 randu ranf ranlux389 ranlux ranlxd1 ranlxd2 ranlxs0 ranlxs1 ranlxs2 ranmar slatec taus transputer tt800 uni32 uni vax zuf so, I got the following code from that idea: is = burststring(init,", "); /* parse init as "[seed[,name]]" */ nis = xstrlen(is,sizeof(string))-1; if (nis > 0) { /* seed is first, but optional */ iseed = natoi(is[0]); if (iseed > 0 || streq(is[0],"+0")) { sprintf(my_gsl_seed,"%s=%s",env_seed,is[0]); } else { iseed = set_xrandom(iseed); sprintf(my_gsl_seed,"%s=%u",env_seed,iseed); } putenv(my_gsl_seed); if (nis > 1) { /* name is second, also optional */ sprintf(my_gsl_type,"%s=%s",env_type,is[1]); putenv(my_gsl_type); } } gsl_rng_env_setup(); /* initialize the rng (name/seed) setup */ my_T = gsl_rng_default; my_r = gsl_rng_alloc(my_T); dprintf(1,"GSL generator type: %s\n",gsl_rng_name(my_r)); dprintf(1,"GSL seed = %u\n",gsl_rng_default_seed); dprintf(1,"GSL first value = %u\n",gsl_rng_get(my_r)); You can see a call to set_xrandom(), that replaces a seed of 0,-1,-2 by seconds since 1970, clock-cycles or PID as seed. We found that to be useful for simulations. In linux there is also /dev/random, but I haven't been able to use that. peter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) 2001-12-19 13:20 ` Peter Teuben @ 2001-12-19 13:20 ` Brian Gough 0 siblings, 0 replies; 14+ messages in thread From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw) To: Peter Teuben; +Cc: gsl-discuss Peter Teuben writes: > yes, I understood that also from the example, but i actually like > the idea of the user giving control of the random number > generator. So in the code the user can supply > seed=0,ran3 where they are both optional. The method of > assigning to gsl_rng_default_type would require me to manually > build a large list of (to me officially unknown) names, whereas the > putenv() method has the nice side-effect that if you say Ok, I see. There is an undocumented function gsl_rng_types_setup() that will give you a list of all valid generators. Look in rng/default.c to see how it is used in gsl_rng_env_setup. I have to document that, and add a function for registering new generator types. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: autoconf usage : -DHAVE_GSL ? 2001-12-19 13:20 autoconf usage : -DHAVE_GSL ? Peter Teuben 2001-12-19 13:20 ` Brian Gough @ 2001-12-19 13:20 ` gsl-discuss 2001-12-19 13:20 ` gsl_poly_eval Peter Teuben 2 siblings, 0 replies; 14+ messages in thread From: gsl-discuss @ 2001-12-19 13:20 UTC (permalink / raw) To: Peter Teuben; +Cc: gsl-discuss On Fri, Sep 07, 2001 at 09:01:31PM -0400, Peter Teuben wrote: > I'd like to have a macro HAVE_GSL, so i can #ifdef my code. I followed some of > the instructions in section 2.4 on automake, and added the gsl.m4 to my > aclocal.m4 and did something like the following in configure.in : > > AM_PATH_GSL(0.9.2, ok=yes, ok=no) > if test "$ok" = "yes"; then > AC_MSG_RESULT(ok, i found GSL) > NEMO_CFLAGS="$NEMO_CFLAGS $GSL_CFLAGS -DHAVE_GSL" > NEMO_LIBS="$NEMO_LIBS $GSL_LIBS" > else > AC_MSG_WARN(could not find GSL library) > fi That's gross. Much better might be: AM_PATH_GSL(0.9.2,[ AC_MSG_RESULT([found GSL]) NEMO_CFLAGS="$NEMO_CFLAGS $GSL_CFLAGS -DHAVE_GSL" NEMO_LIBS="$NEMO_LIBS $GSL_LIBS"],[ AC_MSG_WARN([unable to locate GSL library])]) > My question is about the kludgie looking -DHAVE_GSL. I wanted to use > something like > > > AC_CHECK_LIB(gsl,gsl_version) > > but that fails, gsl_version seems to needs -lgslcblas! (which is actually odd, > if I look at the output of nm..... -static will fix that dependancy, but > AC_CHECK_LIB does not do that) I'd like to know which function/static would be > the one that doesn't need another library. Can that be done with AC_CHECK_LIB? > If so, perhaps this should be added to section 2.4 on the automake macros. Or > perhaps is there a better way to get the HAVE_GSL macro? Then you should do something like: AC_CHECK_LIB(gslcblas, VARIABLE, [ AC_CHECK_LIB(gsl, gsl_version)]) -- albert chin (china@thewrittenword.com) ^ permalink raw reply [flat|nested] 14+ messages in thread
* gsl_poly_eval 2001-12-19 13:20 autoconf usage : -DHAVE_GSL ? Peter Teuben 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` autoconf usage : -DHAVE_GSL ? gsl-discuss @ 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` gsl_poly_eval Brian Gough 2 siblings, 1 reply; 14+ messages in thread From: Peter Teuben @ 2001-12-19 13:20 UTC (permalink / raw) To: gsl-discuss documentation bug: the manual claims the name of this function is gsl_sf_poly_eval, but it's really gsl_poly_eval. (in: gsl/poly.texi) - peter ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gsl_poly_eval 2001-12-19 13:20 ` gsl_poly_eval Peter Teuben @ 2001-12-19 13:20 ` Brian Gough 0 siblings, 0 replies; 14+ messages in thread From: Brian Gough @ 2001-12-19 13:20 UTC (permalink / raw) To: Peter Teuben; +Cc: gsl-discuss Peter Teuben writes: > > > documentation bug: the manual claims the name of this function > is gsl_sf_poly_eval, but it's really gsl_poly_eval. > > (in: gsl/poly.texi) > Thanks, now fixed. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2001-12-19 13:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-12-19 13:20 autoconf usage : -DHAVE_GSL ? Peter Teuben 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` gsl-discuss 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` J.J. Gomez Cadenas 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup) Peter Teuben 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` Peter Teuben 2001-12-19 13:20 ` Brian Gough 2001-12-19 13:20 ` autoconf usage : -DHAVE_GSL ? gsl-discuss 2001-12-19 13:20 ` gsl_poly_eval Peter Teuben 2001-12-19 13:20 ` gsl_poly_eval Brian Gough
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).