[Win32] Failing test with (MinGW) gcc-4.5.2

Hi,

On Win32, using the MinGW port of gcc-4.5.2, I'm getting the following 
failure during 'make check':

make[2]: Entering directory `/c/comp/gsl-1.15/ode-initval2'
FAIL: bsimp/msbdf e5_bigt [1] (1.0190909463048507e-020 observed vs 
1.020144070808528e-020 expected) [1214]
FAIL: bsimp/msbdf e5_bigt [2] (1.0194255784181719e-020 observed vs 
1.0183729939450725e-020 expected) [1215]
FAIL: bsimp/msbdf e5_bigt [3] (3.7405084513304344e-065 observed vs 
3.7366884728539915e-065 expected) [1216]
FAIL: test.exe
==================
1 of 1 test failed
==================

Is this a known issue ? (I'm fairly sure that all tests passed when I used 
the MinGW port of gcc-3.4.5.)

The same test fails irrespective of whether gsl-1.15 has been built 
statically or dynamically.

Cheers,
Rob 

Re: Bug in polynomial root finder

At Sat, 29 Oct 2011 08:22:53 -0700 (PDT),
Munagala Ramanath wrote:
> # shows bug in GSL polynomial root finder
> p = [1, -4, 2, 10, -17, 10, 6, -16, 12, -16, 16, -8, 28, -8, -48, 32]
> roots = GSL::Poly[ p.reverse ].solve

Thanks for the email.  I think that is just a limitation of the solver
algorithm rather than a bug. The algorithm does not work for
arbitrarily high orders and 15th order is probably too high.

--

-- 
Brian Gough

Hydra job gnu:gsl-master:build build 1503725: Success

Hi,

This is to let you know that Hydra build 1503725 of job gnu:gsl-master:build has changed from 'Failed' to 'Success'.

Complete build information can be found on this page: http://hydra.nixos.org/build/1503725

A summary of the build information follows:

Build ID:              | 1503725
Nix name:              | gsl-1.14.27
Short description:     | Native Nix build on i686-cygwin
Maintainer(s):         | bug-gsl <at> gnu.org
System:                | i686-cygwin
Derivation store path: | /nix/store/zj9c3dxz5kfjz7mfwvypbfx8afssinvp-gsl-1.14.27.drv
Output store path:     | /nix/store/vmij4lp1rikvqwmiljz45h969x9xbp82-gsl-1.14.27
Time added:            | 2011-11-05 09:29:59
Build started:         | 2011-11-05 09:18:19
Build finished:        | 2011-11-05 09:29:59
Duration:              | 700s

The build inputs were:

Name        | Type   | Value
------------+--------+--------------------------------------------------------------------------------------
hydraConfig | git    | git://git.savannah.gnu.org/hydra-recipes.git:66f6ba05f05e0580dcdffc9ce1060194193f1f65
nixpkgs     | svn    | https://svn.nixos.org/repos/nix/nixpkgs/trunk:30243
system      | string | i686-cygwin
tarball     | build  | 1501719

Regards,

Re: Bug in polynomial root finder

Thanks for the response.

I have run it on more than 1.6 million polynomials of order 15 and this is
the only one on which it has problems.

I've also run it on some polynomials of order 18 and again it had no problems.

So it seems the order is not the problem, just some corner case with this
particular polynomial.

Ram

________________________________
From: Brian Gough <bjg <at> gnu.org>
To: Munagala Ramanath <amberarrow <at> yahoo.com>
Cc: "bug-gsl <at> gnu.org" <bug-gsl <at> gnu.org>
Sent: Friday, November 4, 2011 3:37 AM
Subject: Re: [Bug-gsl] Bug in polynomial root finder

At Sat, 29 Oct 2011 08:22:53 -0700 (PDT),
Munagala Ramanath wrote:
> # shows bug in GSL polynomial root finder
> p = [1, -4, 2, 10, -17, 10, 6, -16, 12, -16, 16, -8, 28, -8, -48, 32]
> roots = GSL::Poly[ p.reverse ].solve

Thanks for the email.  I think that is just a limitation of the solver
algorithm rather than a bug. The algorithm does not work for
arbitrarily high orders and 15th order is probably too high.

--

-- 

Re: Bug in polynomial root finder

At Sun, 6 Nov 2011 08:38:22 -0800 (PST),
Munagala Ramanath wrote:
> 
> Thanks for the response.
> 
> I have run it on more than 1.6 million polynomials of order 15 and this is
> the only one on which it has problems.
> 
> I've also run it on some polynomials of order 18 and again it had no problems.
> 
> So it seems the order is not the problem, just some corner case with this
> particular polynomial.
> 

Ah, thanks. That is useful information.

Can you confirm what platform you are one and try the program as a
standalone test case in C -- it works fine for me.

#include <stdio.h>
#include <gsl/gsl_poly.h>

int main ()
{
    double a[16] = { 1, -4, 2, 10, -17, 10, 6, -16, 12, -16, 16, -8, 28, -8, -48, 32 };
    double z[16*2];
    int i;

    gsl_poly_complex_workspace *w = gsl_poly_complex_workspace_alloc (16);

Re: [Win32] Failing test with (MinGW) gcc-4.5.2

At Thu, 3 Nov 2011 23:11:34 +1100,
Sisyphus wrote:
> 
> Hi,
> 
> On Win32, using the MinGW port of gcc-4.5.2, I'm getting the following 
> failure during 'make check':
> 
> make[2]: Entering directory `/c/comp/gsl-1.15/ode-initval2'
> FAIL: bsimp/msbdf e5_bigt [1] (1.0190909463048507e-020 observed vs 
> 1.020144070808528e-020 expected) [1214]
> FAIL: bsimp/msbdf e5_bigt [2] (1.0194255784181719e-020 observed vs 
> 1.0183729939450725e-020 expected) [1215]
> FAIL: bsimp/msbdf e5_bigt [3] (3.7405084513304344e-065 observed vs 
> 3.7366884728539915e-065 expected) [1216]
> FAIL: test.exe
> ==================
> 1 of 1 test failed
> ==================
> 
> Is this a known issue ? (I'm fairly sure that all tests passed when I used 
> the MinGW port of gcc-3.4.5.)

Thanks for the email.  I think it was reported by others, I don't use
MinGW so I'm not able to do anything about it.  If someone wants to
send a patch I will apply it, even if it is just to increase the error
tolerances in the test.

Re: Bug in polynomial root finder

The array of coefficients needs to be reversed. Here is the output and modified code:

uname -a
Linux clay 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[This is Linux Mint 11 (katya) 64 bit]

Output [compiled with: gcc -o gsl_poly -O2 -std=c99 gsl_poly.c -lgsl -lgslcblas ]:
 ./gsl_poly
gsl: zsolve.c:78: ERROR: root solving qr method failed to converge
Default GSL error handler invoked.
Aborted

Modified code:
#include <stdio.h>
#include <gsl/gsl_poly.h>

int main ()
{
    double b[16] =
          { 1, -4, 2, 10, -17, 10, 6, -16, 12, -16, 16, -8, 28, -8, -48, 32 },
        a[16], z[16*2];
    int i;

    for ( int j = 0; j < 16; ++j ) {
        a[j] = b[ 16 - j - 1 ];
    }

    gsl_poly_complex_workspace *w = gsl_poly_complex_workspace_alloc (16);

    int status = gsl_poly_complex_solve (a, 16, w, z);

Small Bug in Manual for Random Number Generation

Hello!

I am just reading up things for a talk about random number generation, and I 
think I might have noticed an error in the GSL manual. 
In the Random Number Generation Section, 18.11 Other random number generators 
it says about gsl_rng_minstd, that it is used as standard generator for 
Matlab. But the versions I checked, R2011b (7.13.0.564) and R2007a, use 
Mersenne Twister as standard.

Yours,
Rabea Seyboldt

GSL fails to honor zero's sign at branch cuts

Systems that support signed zero should be careful about the value on 
the branch cuts ("slits"). To quote William Kahan [0]:

"Since all the slits in question lie on either the real or the imaginary 
axis, every point z on a slit is represented in at least two ways, at 
least once with a +0 and at least once with a -0 for whichever of the 
real and imaginary parts of z vanishes. Benignly, ambiguity in z at a 
discontinuity of f(z) permits f(z) to be defined formally continuously, 
except possibly at the ends of some slits, by continuation from inside 
the principal domain. This continuity goes beyond mere formality. By 
analytic continuation, the domain of each of our nine elementary 
functions f(z) extends until it fills out a Riemann Surface; think of 
this surface as a multiple covering wrapped like a bandage around the 
Riemann Sphere and mapped onto it continuously by f. To construct f's 
principal domain, cut the bandage along the slit(s) and discard all but 
one layer covering the sphere. That layer is a closed surface mapped by 
f continuously onto a subset of the sphere. The shadow of that layer 
projected down upon the sphere is the principal domain; it consists of 
the whole sphere, but with slit(s) covered twice. That is why we wish to 
represent slits ambiguously."

The basic convention (adopted in C99, CLTL2, etc. and implemented in 
GCC, GLibC, CLisp, etc.) for branch cuts with only one finite endpoint 
is counter-clockwise continuity (CCC): "the function is continuous as 
the cut is approached coming around the finite endpoint of the cut in a 
counter clock wise direction" (wording from [1]).

GSL falls into the category of systems that should do this, since it 
uses IEEE 754 double precision for constructing complex numbers. 
However, GSL does not distinguish between +0 and -0 on the branch cuts!

gsl 1.15 on mac osx 10.7.2

Dear GSL,

a clean compilation of gsl 1.15 on mac osx lion (10.7.2) yielded errors in the linalg section of the make
check. In particular the SVD decomposition failed to converge.
I downloaded gsl 1.15 from the main mirror

MD5 (gsl-1.15.tar.gz) = 494ffefd90eef4ada678c306bab4030b
uname -a:   Darwin macjmb.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT 2011;
root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

Reproducible steps to create the errors in Make check

autoreconf -i -f -v
./configure
make
make -k check  1> make_check.out 2> make_check.err

I attach the two output files for your convenience.

Joost Bakker

_______________________________________________
Bug-gsl mailing list
Bug-gsl <at> gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gsl