autoconf usage : -DHAVE_GSL ?

autoconf usage : -DHAVE_GSL ?

[Peter Teuben]

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

Re: autoconf usage : -DHAVE_GSL ?

[Brian Gough]

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.

Re: autoconf usage : -DHAVE_GSL ?

[gsl-discuss]

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)

Re: autoconf usage : -DHAVE_GSL ?

[Peter Teuben]

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

fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup)

[Peter Teuben]

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

Re: fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup)

[Brian Gough]

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

Re: fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup)

[Peter Teuben]

> 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

Re: fprintf(stderr,...) output in GSL routines (gsl_rng_env_setup)

[Brian Gough]

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.

Re: autoconf usage : -DHAVE_GSL ?

[Brian Gough]

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)

RE: autoconf usage : -DHAVE_GSL ?

[J.J. Gomez Cadenas]

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)

RE: autoconf usage : -DHAVE_GSL ?

[Brian Gough]

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.

Re: autoconf usage : -DHAVE_GSL ?

[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)

gsl_poly_eval

[Peter Teuben]

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

Re: gsl_poly_eval

[Brian Gough]

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.