From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14863 invoked by alias); 21 Mar 2007 18:02:14 -0000 Received: (qmail 14849 invoked by uid 22791); 21 Mar 2007 18:02:13 -0000 X-Spam-Check-By: sourceware.org Received: from alnrmhc14.comcast.net (HELO alnrmhc14.comcast.net) (206.18.177.54) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Mar 2007 18:02:06 +0000 Received: from hippogriff.homeunix.org ([75.71.67.96]) by comcast.net (alnrmhc14) with ESMTP id <20070321180204b14005agfoe>; Wed, 21 Mar 2007 18:02:05 +0000 Received: by hippogriff.homeunix.org (Postfix, from userid 1000) id 6183A8344; Wed, 21 Mar 2007 12:02:06 -0600 (MDT) Date: Wed, 21 Mar 2007 18:02:00 -0000 From: Patrick Alken To: gsl-discuss@sourceware.org Subject: Re: generalized eigensystems Message-ID: <20070321180206.GA13688@hippogriff.physics.drexel.edu> References: <20070313050349.GA22421@hippogriff.physics.drexel.edu> <87ejni7vqw.wl%bjg@network-theory.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <87ejni7vqw.wl%bjg@network-theory.co.uk> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00064.txt.bz2 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1685 > Here is an interesting test case, it aborts with a "shouldn't get > here" error in extended precision but works in double precision (via > GSL_IEEE_MODE). > > Might be worth also looking at the previous case you had that went > away when changing the optimisation - did you try it in > double-precision? I could not reproduce the exact error you got, but that same test case is giving incorrect eigenvalues when gsl is compiled with -O2 with gcc 4.1.2 with single precision. When GSL_IEEE_MODE is set to double-precision, it gives correct output. If I compile libgsleigen without -O2, it gives correct output in both cases...very odd. I'm still looking into this. It may be an issue with not properly detecting when a matrix element has become negligible. When trying to debug this, I came across the following issue: when GSL_IEEE_MODE is set to double-precision, gsl_finite(GSL_POSINF) fails. I have attached a sample test program to demonstrate this: > gcc --version gcc (GCC) 4.1.2 > gcc -g -Wall -o testfin testfin.c -lgsl -lgslcblas > setenv GSL_IEEE_MODE "double-precision" > ./testfin GSL_IEEE_MODE="double-precision,trap-common" Floating exception (core dumped) > gdb testfin core ... Program terminated with signal 8, Arithmetic exception. #0 0xb7ef3578 in gsl_finite (x=inf) at infnan.c:103 103 const double y = x - x; ... > unsetenv GSL_IEEE_MODE > ./testfin s = 0 Is this a known issue? I'm trying to use gsl_finite() in testgen to better sort the eigenvalues so I can compare them to lapack if there are infinities present. Basically I'm getting segfaults all over the place whenever I try to access nans/infs in double-precision mode. Patrick Alken --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="testfin.c" Content-length: 217 #include #include #include int main() { double a; int s; gsl_ieee_env_setup(); a = GSL_POSINF; s = gsl_finite(a); printf("s = %d\n", s); return 0; } --MGYHOYXEY6WxJCY8--