[Help-gsl] gsl-1.14 linalg test: FAIL: QRPT_update m(5,3)
Hi Brian, I got an unexpected test failure in gsl-1.14 make[1]: Entering directory `/tmp/GSL/gsl-1.14/linalg' ( 5, 3)[2,1]: 0.00349227666295463118 0.00349227666295377857 FAIL: QRPT_update m(5,3) [182] FAIL: QRPT Rank-1 Update [191] FAIL: test == 1 of 1 test failed == make[1]: *** [check-TESTS] Error 1 My setup is as follows: gsl-1.14; Ubuntu 10.04 (Lucid Lynx) linux on x86 (32bit) Intel CoreDuo, gcc-4.4.3 compiled with '-g' (or -ggdb) debug option and '-D_GNU_SOURCE' : Optimizing build with -O2 passes all the tests OK. I can make it fail by: cd linalg linalg make clean linalg make check CFLAGS=-g I can make it pass by linalg make clean linalg make check CFLAGS=-O2 when compiled with CFLAGS=-g -O2 the test passes OK. It seems that the problem is limited to -g (-ggdb) with no optimization. IMHO, one possibility might be an uninitialized variable somewhere that gets random garbage when compiled with -g. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
[Help-gsl] Re: gsl-1.14 linalg test: FAIL: QRPT_update m(5,3)
On Wed, Dec 22, 2010 at 13:39, Leo Razoumov slonik...@gmail.com wrote: Hi Brian, I got an unexpected test failure in gsl-1.14 I think I found a fix. The problem is due to infamous extended precision (80 bits) registers and 64-bit doubles. By trial and error I found out that compiling with make CFLAGS=-ggdb -msse2 -mfpmath=sse results in all tests passing OK. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] GPLv3 or LGPL?
On Tue, Dec 7, 2010 at 16:38, andrew.lu...@l-3com.com wrote: I'm curious why is a library set using GPLv3 instead of LGPL? This issue has been discussed on this list multiple times. Google is your friend. Basically, the authors are free to choose whatever license they want and they happened to choose GPL rather than LGPL. End of story. --Leo-- P.S. FWITW, I would personally prefer LGPL for GSL. GPL is too viral for a library. ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] cannot browse GSL's bzr repository at savannah
On Thu, Nov 11, 2010 at 10:43, Brian Gough b...@gnu.org wrote: Unfortunately the browsing is broken, due to problems with the web server, but the repository itself is fine if you checkout with bzr directly. I'm trying to get the browsing fixed, rather than working around it, as that will benefit all projects on Savannah. -- Brian Gough I tried sh$ bzr branch bzr://bzr.savannah.gnu.org/gsl/trunk using Ubuntu 9.04 Linux with bzr version 1.13.1 . The attempt resulted in an error KeyError: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' Apparently, bzr repository format is rapidly evolving and would require me to install new version manually (I do not want to upgrade my Linux distro for other reasons). Git or Mercurial, on the other hand, go to extra length to keep their internal format stable and backward compatible. No wonder that bzr gets little traction outside of FSF or Canonical. I understand that decision to move to bzr is final, but might be a kind soul would provide a bzr-git bridge. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
[Help-gsl] Re: GIT or Bazaar (bzr) for GSL development
On 2010-10-12, Jakub Narebski jna...@gmail.com wrote: I don't think that Bazaar is the standard GNU distributed version control system, but from all open source DVCS (Git, Mercurial, Darcs, Monotone, Bazaar) this is the one that is GNU project. Well, trying to browser brz repo at savannah (official GNU site) results in the following error. Trying http://bzr.savannah.gnu.org/lh/gsl with Firefox 3.6.10 I get error message loggerhead disabled due to instability; if you're interesting in maintaining it, please contact us. On the other hand, browsing git repos at savannah works just fine http://git.savannah.gnu.org/gitweb/?p=gsl.git;a=summary Anyway, is the git repo at git://git.sv.gnu.org/gsl.git up to date? --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
[Help-gsl] GIT or Bazaar (bzr) for GSL development
Hi List, I have been following GSL development using its GIT repository on git://git.sv.gnu.org/gsl.git In May 2010 GSL development moved from GIT to Bazaar (bzr) which is not well supported by savannah.gnu.org. For example, browsing bzr repositories on savannah is broken. I noticed that GSL git repository is still being updated. What is the status of those git updates? Is it a mirror of the main bzr repository? Is it OK to keep following the GIT repo instead of bzr? --Leo-- P.S. Brian, in your announcement of git-bzr move you call bazaar the standard GNU distributed version control system. What makes it the standard GNU vcs? Is it superior to git? ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] error in Schur decomposition of a non-symmetric matrix ?
On 2010-03-22, Francesco Abbate francesco@gmail.com wrote: Hi all, The problems seems to be about the Schur decomposition formula. What seems to be true is that: A = Z T Z^(-1) and not that: A = Z T Z^T as asserted in the documentation. Z is an orthogonal matrix and Z^(-1) = Z^T. Therefore, I do not see any problem neither with GSL nor with its documentation. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Renaming versions of the libraries?
On 2010-02-05, Brian Gough b...@gnu.org wrote: I find it an advantage to use the same names and different directories rather than different names as it is easy to change the library at runtime without modifying the executable via LD_LIBRARY_PATH. -- Brian Gough I agree with Brian. I find it very useful to have the *same* lib-name for different versions of the same library but place them in different directories. Using a starter script like #!/bin/sh LD_LIBRARY_PATH=/blah_plah:$LD_LIBRARY_PATH exec $* I can choose at _run_ time what version of library to use without any need to recompile/relink my executable. I also maintain optimized and debug versions of GSL in two different directories. It is faster and easier to modify LD_LIBRARY_PATH than to meddle with Makefiles. Just my two cents. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Renaming versions of the libraries?
On 2010-01-28, Brian Gough b...@network-theory.co.uk wrote: At Wed, 27 Jan 2010 11:31:38 +, [..snip..] The situation is that GNU packages always compile with debugging (-g -O2) by default, so it should not be necessary to make a separate debugging version -- it's part of the GNU philosophy that anyone should be able to examine any program on the system. I've added a note saying that to the INSTALL file. Unfortunately many distributions don't follow this approach. This is a commendable philosophy which, unfortunately, does not work in practice. Due to optimizations, binary code compiled with -g -O2 does not follow the source code. Stepping through a program with a debugger (gdb) is extremely painful. Some variables are optimized out, some functions get inlined, instructions are not in sync with source code. For debugging, I compile my code with -g or -ggdb and no any optimization flags at all. This policy serves me well. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] [PATCH] GSL_VERSION_MAJOR, GSL_VERSION_MINOR numeric macros
On 2010-01-18, Brian Gough b...@gnu.org wrote: At Fri, 15 Jan 2010 10:32:34 -0600, Rhys Ulerich wrote: Attached is a patch like Leo's that performs the autoconf voodoo to get the version numbers automatically from VERSION at configure time. It builds atop head. Note that it uses AC_PROG_SED, which may/may not be an issue depending on GSL's portability requirements. I've checked in a change for this ffb8708d2cf636801de0b9f1f03c65a5ab0bcb13 Brian, thanks for applying the patch. But I think that a proper attribution to the patch author Rhys Ulerich rhys.uler...@gmail.com would be nice. It is too late to change the Author: field of the git commit (the commit is already published) but the ChangeLog file should have a proper attribution to Rhys. Unlike git commit, it is never too late to modify a file. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
[Help-gsl] [PATCH] GSL_VERSION_MAJOR, GSL_VERSION_MINOR numeric macros
Added GSL_VERSION_MAJOR, GSL_VERSION_MINOR macros with numeric constant values usable in preprocessor conditionals. Signed-off-by: Leo Razoumov slonik...@gmail.com --- gsl_version.h.in |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/gsl_version.h.in b/gsl_version.h.in index 25bf3a3..c95f96f 100644 --- a/gsl_version.h.in +++ b/gsl_version.h.in @@ -17,6 +17,9 @@ __BEGIN_DECLS #define GSL_VERSION @VERSION@ +#define GSL_VERSION_MAJOR 1 +#define GSL_VERSION_MINOR 13 + GSL_VAR const char * gsl_version; __END_DECLS -- 1.6.5.7.LR1 ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] [PATCH] GSL_VERSION_MAJOR, GSL_VERSION_MINOR numeric macros
On 2010-01-14, Rhys Ulerich rhys.uler...@gmail.com wrote: It looks like the existing GSL_VERSION #define was set automagically by autoconf via @vers...@. The patch you submitted seems to hard code two fixed values. Unfortunately, I am unfamiliar with how autoconfig generator works. Please, feel free to modify the patch. Actually, instead of splitting VERSION string I would rather concatenate VERSION from MAJOR and MINOR values. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] problem using gsl_version.h file
On 2010-01-13, Brian Gough b...@gnu.org wrote: At Tue, 5 Jan 2010 10:21:41 +0100, Francesco Abbate wrote: Please let me know if there is an easy way to check the GSL version at C preprocessor level, may be I've missed something. No, sorry, the autoconf method of examining the header file before compilation is the only one supported. -- Brian Gough Is it possible to add numeric version macros for major and minor versions going forward? IT does not cost much but it makes life of many people easier. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] GPL violation?
On 2009-12-10, Brian Gough b...@gnu.org wrote: At Wed, 9 Dec 2009 23:27:16 +1300, Is this the MET Fortran package? It sounds like it. If so, the situation is that I agree with you entirely and I got the same answer from them. I do believe that if the program is distributed (even in purely source form) it should be under the GPL, a compatible license, or public domain. On a somewhat related note, can users of the GSL choose to make their code GPLv2 if it is still compatible with the 'old' GSL versions that didn't have GPLv3? While that might be possible I don't think it would be desirable, if someone wanted to use GPLv2 only for everything it would prevent people from using their code with new versions of the GSL under GPLv3. The GPLv3 is a state-of-the-art free software license and I would encourage everyone to use it. -- Brian Gough IANAL, but I think there are only three legal ways to use GPL licensed code (1) Do what ever you want but do *NOT* distribute the code at all (2) License derivative work under GPL and distribute (3) License your code under your favorite license, distribute (in source form) without GPL code and let end-user to download GSL, compile it, compile your code and link it all together. This is the worst distribution method for the reasons that are quite obvious. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
[Help-gsl] Why not LGPL?
GSL is licensed under GPL which precludes its use together with less restrictive libraries in the same application. To address this issue LGPL license (Library GPL) was created. Is there any good reason for GSL to stick with GPL over LGPL?? --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] Re: gsl c++ wrapper ?
On 8/31/09, Rhys Ulerich rhys.uler...@gmail.com wrote: Designing a good C++ wrapper to any matrix library is difficult provided one tries to keep C++ semantics. It may be easier, if you have a favorite C++ matrix/vector library, to design a GSL-wrapper for the matrix/vector library itself. For example, write wrappers that accept ublas [1] or eigen2 [2] matrices and vectors, wrap the same storage with gsl_matrix and gsl_vector views, and then call the GSL methods directly. Such GSL-ublas or GSL-eigen2 bindings would be independent of both projects, mainly boilerplate, and easy to test for correctness. - Rhys Many good and tested libraries like LAPACK have come from Fortran and use column-major matrix storage incompatible with GSL. One cannot simply wrap them up in some sort of GSL objects that can be passed to GSL functions. --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
Re: [Help-gsl] nested function calls
On 4/9/09, Holger Perlt holger.pe...@itp.uni-leipzig.de wrote: Is it possible to use a gsl-function as argument of another gsl-function? Example: Finding the zeroth of a one-parameter integral: One could use one of the gsl-root functions with the argument-function being the integral over a one-parameter function. One wants to determine the value of the parameter where this integral vanishes. Holger GSL functions are regular C-functions and should be used as such. In your particular example, please, see GSL documentation, section 32 One dimensional Root-Finding, subsection 32.10 Examples on how to pass functions as arguments to root solvers. By the way, implementation of your function could contain integrals, etc. Hope it helps, --Leo-- ___ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl
[Help-gsl] [PATCH] BUG FIX: allow NULL pointers in gsl_matrix_free, gsl_rng_free, gsl_vector_free
Long standing C-language idiom allows one to pass NULL pointer
as an argument to various free functions (see man free).
Unfortunately, GSL functions gsl_matrix_free, gsl_rng_free,
gsl_vector_free (and possibly several more) do not follow this
convention and will crash the program if called with NULL pointer.
This simple patch fixes the problem.
--Leo--
---
matrix/init_source.c |1 +
rng/rng.c|1 +
vector/init_source.c |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
88888888
diff --git a/matrix/init_source.c b/matrix/init_source.c
index c0fa819..f8302ff 100644
--- a/matrix/init_source.c
+++ b/matrix/init_source.c
@@ -182,6 +182,7 @@ FUNCTION (gsl_matrix, alloc_from_matrix) (TYPE(gsl_matrix)
* mm,
void
FUNCTION (gsl_matrix, free) (TYPE (gsl_matrix) * m)
{
+ if (!m){ return; }
if (m-owner)
{
FUNCTION(gsl_block, free) (m-block);
diff --git a/rng/rng.c b/rng/rng.c
index 604de88..be9ca6f 100644
--- a/rng/rng.c
+++ b/rng/rng.c
@@ -148,6 +148,7 @@ gsl_rng_print_state (const gsl_rng * r)
void
gsl_rng_free (gsl_rng * r)
{
+ if (!r) { return; }
free (r-state);
free (r);
}
diff --git a/vector/init_source.c b/vector/init_source.c
index 7034f6d..6c62715 100644
--- a/vector/init_source.c
+++ b/vector/init_source.c
@@ -162,6 +162,7 @@ FUNCTION (gsl_vector, alloc_from_vector) (TYPE(gsl_vector)
* w,
void
FUNCTION (gsl_vector, free) (TYPE (gsl_vector) * v)
{
+ if (!v){ return; }
if (v-owner)
{
FUNCTION(gsl_block, free) (v-block) ;
--
1.6.0.6.LR1
___
Help-gsl mailing list
Help-gsl@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gsl
