inaccurate tabulated values in gsl-1.11/randist/gausszig.c

Hi,

The tables in the above file, implementing the Ziggurat method for Gaussian, carry inaccurate numerical
values.  The problem is most likely due to the inaccurate value of PARAM_R, which is defined as 3.44428647676.

The accurate value should be 3.442619855899.  Even though the difference seems small, it affects all the
values in all the tables to various degree.  The extent of this impact to the accuracy of user programs is not
known.  By the way, the accurate value did appear in the original paper by Marsaglia and Tsang.

The reason for the inaccurate values is due to the use of erfc approximation in the original C program that
generates the Ziggurat tables ( I dug up that C program somewhere from the Web).  It is easy to fix by using the
accurate erfc function in this program to re-generate the tabulated values.

Joseph Pang

Nelder Mead bug

Hi everyone,

Nelder Mead , i.e. simplex search has a bug. In the function
static int
nmsimplex_iterate (void *vstate, gsl_multimin_function * f,
                   gsl_vector * x, double *size, double *fval)

in multimin/simplex.c
a piece of code that determines the highest , second highest and lowest
vertex fails when first value in y1 is the highest.
It returns second highest equal to the highest. Later that influence
decision in the algorithm.

FIX:
add lines:
  ds_hi = gsl_vector_get (y1, 1);
  s_hi = 1;
before the loop

CODE SHOULD LOOK LIKE THIS:

...
 if (xc->size != x->size)
    {
      GSL_ERROR("incompatible size of x", GSL_EINVAL);
    }

  /* get index of highest, second highest and lowest point */

  dhi = ds_hi = dlo = gsl_vector_get (y1, 0);

Re: Optimization level problem

At Thu, 10 Apr 2008 19:13:54 -0400,
Daniel Platt wrote:
> Using gcc (GCC) 4.3.0, on Mac OS X 10.5.2, make check fails in the  
> gsl-1.10/sort/ directory.  The makefile in the gsl-1.10/sort/  
> directory must be modified so that 'CFLAGS = -g -O' (rather than  
> 'CFLAGS = -g -O2').  Then gsl-1.10 passes make check.

Thanks for the bug report.  I've tried this with gcc-4.3.0 on x86 and
couldn't reproduce it (with -fsigned-char and -funsigned-char) so I
assume it must be something specific to Mac OS.

--

-- 
Brian Gough

Problem with GSL 1.9

Hello,
I'm trying to build GSL 1.9 on an IBM Power5 machine running AIX 5.3. I 
would like to use the native compiler, namely xlc version 8.0. I was able 
to configure and compile the library without problems, but when running 
make check, I get some test failures. Please find in attachment the output of 
make check.

Any help will be greatly appreciated, thank you in advance, best regards,
Michela Botti

-- 
Michela Botti - PhD

*******************************************************************************
CASPUR 
Consorzio interuniversitario per le Applicazioni del Supercalcolo Per 
Universita'à e Ricerca

E-mail:               m.botti <at> caspur.it
Phone:                +39 06 44486730
web:                  www.caspur.it/~botti 

*******************************************************************************

   Life is what happens to you while you are busy making other plans.
   John Lennon

Making check in gsl
Target "check" is up to date.
Making check in utils

Re: Problem with GSL 1.9

Hello again!
I think I found out what the problem was: I built the library with the -O3 
flag, that causes the -nostrict option to be enabled. This affects the accuracy
of the results and causes some of the tests to fail. The problem can be solved
by adding -qstrict to the CFLAGS (I experienced the same behaviour with Gsl 
1.11).

Best regards
Michela Botti

--

-- 
Michela Botti - PhD

*******************************************************************************
CASPUR 
Consorzio interuniversitario per le Applicazioni del Supercalcolo Per 
Universita'à e Ricerca

E-mail:               m.botti <at> caspur.it
Phone:                +39 06 44486730
web:                  www.caspur.it/~botti 

*******************************************************************************

   Life is what happens to you while you are busy making other plans.
   John Lennon

Complex: gsl_complex_div_real bug

Hi
There is a bug in the implementation of gsl_complex_div_real  
(gsl_complex a, double x), from the 1.9 package in the complex/math.c  
file.

The code currently is:

gsl_complex
gsl_complex_div_real (gsl_complex a, double x)
{                               /* z=a/x */
   gsl_complex z;
   GSL_SET_COMPLEX (&z, GSL_REAL (a) / x, GSL_IMAG (a) / x);
   return z;
}

However in the situation where GSL_REAL(a) != 0 && GSL_IMAG(a) == 0  
and x != 0 we get the imag part of a set to INF when really it should  
be zero. Since the imag part of x is actually zero.

Perhaps this is simply a interpretation of the intent of this  
function, it does work if you're just trying to do a simple scalar  
divide of the complex number. I thought it was meant to provide the  
functionality of dividing a number in C by a number in R ( which is  
also in C) but it doesn't quite work.

Suggested change would be to either point out that this is intended to  
be a purely scalar divide (and not really reflective of how C / R  
division should work for which you should use the C/C division and  
cast your float into a C number) or put in some kind of simple if
	

Use of inline keyword in GSL 1.11

Hello,

I'm trying to build GSL 1.11 with a compiler that doesn't support the
inline keyword.

HAVE_INLINE is not defined, but there seems to be some use of the
inline keyword in siman.c that doesn't use a #ifdef HAVE_INLINE check.

Regards,

Albert

Re: how to find gsl_stats_wtss'

At Wed, 30 Apr 2008 12:23:10 +0900,
yeon-ki kim wrote:
> I am trying an example program for B-splines at
> 
> http://www.gnu.org/software/gsl/manual/html_node/Example-programs-for-B_002dsplines.html
> When I tryied to compile it gave an error undefined reference to
> `gsl_stats_wtss'.
> gcc mytest.c -o mytest.c -l gsl
> /tmp/cceNPx2N.o: In function `main':
> mytest.c:(.text+0x431): undefined reference to `gsl_stats_wtss'
> collect2: ld returned 1 exit status
> -- 
> 
> It seems the program cannot find the function gsl_stats_wtss.
> Could you give me how I can solve the problem?

You need gsl-1.11 for that function, previous versions do not have it.

--

-- 
Brian Gough

Re: inaccurate tabulated values in gsl-1.11/randist/gausszig.c

At Fri, 2 May 2008 10:22:40 -0700 (PDT),
Joseph Pang wrote:
> The tables in the above file, implementing the Ziggurat method for
> Gaussian, carry inaccurate numerical values.  The problem is most
> likely due to the inaccurate value of PARAM_R, which is defined as
> 3.44428647676.
> 
> The accurate value should be 3.442619855899.  Even though the
> difference seems small, it affects all the values in all the tables
> to various degree.  The extent of this impact to the accuracy of
> user programs is not known.  By the way, the accurate value did
> appear in the original paper by Marsaglia and Tsang.
> 
> The reason for the inaccurate values is due to the use of erfc
> approximation in the original C program that generates the Ziggurat
> tables ( I dug up that C program somewhere from the Web).  It is
> easy to fix by using the accurate erfc function in this program to
> re-generate the tabulated values.

Hello,
Thanks for your email.  In the gausszig.c file there was a note which
says

   * 2) use an acceptance sampling from an exponential wedge
   * exp(-R*(x-R/2)) for the tail of the base strip to simplify the
   * implementation.  The area of exponential wedge is used in
   * calculating 'v' and the coefficients in ziggurat table, so the
   * coefficients differ slightly from those in the Marsaglia and
   * Tsang paper.

Re: Complex: gsl_complex_div_real bug

At Mon, 5 May 2008 13:37:08 -0700,
chris coleman-smith wrote:
> There is a bug in the implementation of gsl_complex_div_real  
> (gsl_complex a, double x), from the 1.9 package in the complex/math.c  
> file.

Can you send a small program which demonstrates the problem.  Thank
you.

--

-- 
Brian Gough