Re: Test release for GSL 2.8
> Can you make sure you are working with the latest git code? [...] It is: current git code works on all the machines I build on (el8, debian unstable, ubuntu 22.04, mint 21.3) with various compilers -- gcc-12, gcc-13, and gcc-14. Note that the for loop limit of "N - 1" when N is a 0 unsigned is a bug, and a check returning error if N <= 0 is necessary. I'm guessing that in the past this got caught with malloc(0) returning NULL, but that seems to be the unusual behavior nowadays, with malloc(0) returning an unusable address but that is still a valid arg for free() and realloc(). Of course this might exist in many other places in our linear algebra, so a more comprehensive review of that is needed.
Re: Test release for GSL 2.8
Dear Patrick and help-gsl,
I had found, a few days ago, a test failure in interpolation/test.c.
Then just yesterday (May 10) there was a revert of interpolation/test.c to a
previous version, which yanked out the test failure I had been investigating.
But the problem still exists, so let me outline here what I found and make some
suggestions.
The test_cspline4() in git hash e647c6484702b638062d6e2154055f6535790cd7 has a
failure.
The problem has two parts: what brings it out, and what
1. test_cspline4() calls make_xy_table() with an argument of 2, which is not OK
- I guess you need at least 3 to do csplines, and things go wrong down the line
when you start doing linear algebra.
The test should be updated to have an argument of 3, or the cspline subsystem
should be updated to warn about that.
2. the real problem is that all the intervening function calls do not check for
that size properly. At one point two gets subtracted from it, and we end up
with calls to malloc(0). Note that if by chance we had called with 1 or 0, we
might end up with malloc(-1) or malloc(-2).
The behavior of malloc(0) surprised me: I had thought it would just return
NULL, but the man page states:
"""The memory is not initialized. If size is 0, then malloc() returns either
NULL, or a unique pointer value that can later be successfully passed to
free()."""
which means that this code in tridiag.c:
static
int
solve_tridiag(
const double diag[], size_t d_stride,
const double offdiag[], size_t o_stride,
const double b[], size_t b_stride,
double x[], size_t x_stride,
size_t N)
{
int status = GSL_SUCCESS;
double *gamma = (double *) malloc (N * sizeof (double));
double *alpha = (double *) malloc (N * sizeof (double));
double *c = (double *) malloc (N * sizeof (double));
double *z = (double *) malloc (N * sizeof (double));
if (gamma == 0 || alpha == 0 || c == 0 || z == 0)
{
GSL_ERROR("failed to allocate working space", GSL_ENOMEM);
}
else
does not capture this kind of error, and we end up with bad access, since the
interpolation index arithmetic is not up to handling a size of 2 (and hence N
of 0).
I would suggest some things:
a. gsl vectors allow a size of zero, so we should not trap at the level of the
gsl_vector subsystem
b. tridiag.c needs to require N > 0. Right now it looks at the return values
of malloc():
double *gamma = (double *) malloc (N * sizeof (double));
double *alpha = (double *) malloc (N * sizeof (double));
double *c = (double *) malloc (N * sizeof (double));
double *z = (double *) malloc (N * sizeof (double));
if (gamma == 0 || alpha == 0 || c == 0 || z == 0)
{
GSL_ERROR("failed to allocate working space", GSL_ENOMEM);
}
else
and then it does unsigned arithmetic here:
for (i = 1; i < N - 1; i++)
{
alpha[i] = diag[d_stride * i] - offdiag[o_stride*(i - 1)] * gamma[i -
1];
where N-1 is:
(gdb) print N-1
$50 = 18446744073709551615
(gdb)
so clearly a bug in allowing N to be zero. Maybe something like:
if (N <= 0)
{
GSL_ERROR("matrix size must be positive", GSL_EDOM);
}
else if (gamma == 0 || alpha == 0 || c == 0 || z == 0)
{
GSL_ERROR("failed to allocate working space", GSL_ENOMEM);
}
else
and probably also do that kind of checking in the higher level function
gsl_linalg_solve_symm_tridiag(), and probably many other parts of linear
algebra. This is a real project to examine the linear algebra package.
c. take cspline_init() and give it a check on size, insisting that it be >= 3.
Re: cross compiling gsl for arm cortex M4 (nrf52)
Dear GSL bug followers, Julius and I just had a session where we shared screens from Austria to New Mexico and figured it out. This might be interesting to others who cross-compile gsl, so I'll show you the final bit that was missing. After setting C_INCLUDE_PATH and other paths correctly, Julius was running this configure line: ./configure CC=/usr/local/gcc/bin/arm-none-eabi-gcc CXX=/usr/local/gcc/bin/arm-none-eabi-gcc LD=/usr/local/gcc/bin/arm-none-eabi-gcc AR=/usr/local/gcc/bin/arm-none-eabi-ar OBJCOPY=/usr/local/gcc/bin/arm-none-eabi-objcopy CFLAGS="-I/crosscompilearea/gsl-2.7.1/gsl -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=soft" CXXFLAGS="-mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=soft" LDFLAGS="-I/crosscompilearea/gsl-2.7.1/gsl --specs=nano.specs --specs=nosys.specs -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=soft" C_INCLUDE_PATH=“/crosscompilearea/gsl-2.7.1/gsl" --target=arm-none-eabi --host=arm-none-eabi Notice how you specify the Makefile variables CC, CXX, LD, AR, OBJCOPY, CFLAGS. It turns out that you get *most* of the way there, but not all the way: the "ranlib" program also gets called in cross-compiling, and his computer's native ranlib was being called instead of the cross-compiling one for his target ARM architecture. Once he put: RANLIB=/usr/local/gcc/bin/arm-none-eabi-ranlib to that litany it worked.
Re: cross compiling gsl for arm cortex M4 (nrf52)
> [...] those are not include but rather > missing src file errors, e.g. undefined reference to `gsl_rng_get’ You don't give a transcript of the error (hint...), so I'm not sure, but here are some thoughts: 1. You got farther than before, since now you have a link error instead of a compile error. 2. You have -I stuff in LDFLAGS, which doesn't do anything - you'd want -L instead, something like -L/crosscompilearea/gsl-2.7.1/lib/otherlibprefixes 3. I would recommend using LIBRARY_PATH instead, and having in there the full path to where you have the libgslsomething.so and libgslsomething.a files. 4. Apart from having a not-belonging -I option in LDFLAGS (it should be in CFLAGS and CXXFLAGS), you also seem to have put unneeded quotes, and the first of them is a non-ascii double quote. I don't know if this causes confusion, but it might. Write to me privately and we can have a phone call or share screens in a jitsi call.
Re: cross compiling gsl for arm cortex M4 (nrf52)
Dear Julius, Your problem seems like it might have a straightforward solution. Whenever you do a lot of setting of CC and CXX and LD you might also want to set C_INCLUDE_PATH and CPLUS_INCLUDE_PATH (and maybe when you get to linking also LIBRARY_PATH). I would try finding the full path to the gsl_minmax.h file. Let's say it's in /mycrosscompilearea/stuff/include/gsl/gsl_minmax.h. Then, noting that what's being #included is gsl/gsl_minmax.h, and I would say something like C_INCLUDE_PATH=/mycrosscompilearea/stuff/include:$C_INCLUDE_PATH And the same for LDFLAGS and (if you use C++) for CPLUS_INCLUDE_PATH. You might also be able to put a -I option into the CFLAGS setting you are already using. And I would also investigate using pkg-config -- I have not used it in cross-compiling, so it might not work for you, but you can set your PKG_CONFIG_PATH to include /mycrosscompilearea/stuff/lib/wherever_gsl.pc_is and then use the usual: pkg-config gsl --cflags pkg-config gsl --libs Feel free to contact me further if you want to look at this together.
Re: Reg :: Non Uniform FFT
> Is there any chance in future to add this function to gsl [...] ? Can you point to (a) how it's been done in other libraries - what API did they have for it and so forth? and (b) what publications there are on this?
Re: Reg., Installation query
Dear Chella, When asking for help with a problem you need to give more information about what you did. Your email does not say how you tried to install gsl. Did you try to install from source? From a binary package? What version of CentOS? (7, 8, 9?) What version of gsl? And what command did you type to do the installation. Note that CentOS comes with gsl in the "EPEL" repositories (although CentOS7 ships with an oldish one), so you do something like: sudo yum update sudo yum install epel-release sudo yum install gsl gsl-devel If I could make a guess from your mention of a "lib-apt" package, I would say that your approach to installing might have been that you mistakenly tried to put a debian/ubuntu package onto a CentOS system, which will not work. But that's just guesswork: I would really need the answer to the questions above. Feel free to send me the information I asked for (privately so we don't burden the list with details).
Re: First ever GSL Technical Report (ALFs)
> I suggest archiving on Zenodo https://zenodo.org/ Zenodo works well for this and gives you a citable location and a DOI; I put the gsl design document on there, so if you create a gsl community then we can have 2 things :-)
Re: First ever GSL Technical Report (ALFs)
Patrick, this is a great paper. It shows the same care you apply to
maintaining gsl. The writing is also very clear, and I love the table of
acronyms :-). Do you plan to submit for publication in a numerical analysis
journal, or submit to the arXiv?
The only previous quasi-report had been the ongoing design document that I kept
going with James and Brian in the early years, but it is a working design doc,
not anything of the scope you have shown here.
Tiny suggestions: alignment of equation 36 on page 5: "l >= 1" could be moved
quite a bit to the left. Maybe an extra & to make it match the start of the l
>= 1, m > 0.
You might also want to also cite the reference manual (as we ask people to do
when they use gsl :-) ). A recent bibtex skeleton on that is the 2019 Network
Theory edition.
@book{gslteam2019gnuscientificlibrary,
title={GNU Scientific Library Reference Manual},
author={Galassi, Mark and Davies, Jim and Theiler, James and Gough, Brian and
Jungman, Gerard and Alken, Patrick and Booth, Michael and Rossi, Fabrice and
Ulerich, Rhys},
year={2019},
isbn={9780954612078},
publisher={Network Theory Limited}
}
Re: Installing GSL on Windows to use with Visual Studio Code
Dear Vicent, I'm delighted that you are trying to use GSL, and thank you for working with the inconvenience of installing on Windows. At first I thought that if you did not have a UNIX-like "shell" (either cygwin or MinGW or WSL) to run ./configure then you must be using visual studio, but then you mentioned: > (installing Visual Studio to not really use it seems a lot > to me!). So I was puzzled, thinking "what compiler do you have?". I looked more closely at your original email and saw that you mention that you are using MinGW. Note that MinGW is the "minimalist GNU for Windows" and it comes with a shell that should be able to run ./configure scripts, so I think you might already have what you need. I don't use it myself since I don't use Windows, but you could start with the docs at: https://sourceforge.net/p/mingw-w64/wiki2/Home/ I have this vague memory that MSYS is the part that gives you the shell environment. I hope this helps.
Re: physical constants that might need updating
> I agree it would be best to stay current [...] I am concerned > that such a change could potentially break existing > software which might depend on certain values. Yeah, I agree that it is a problem, but in the end the old numbers need to be seen as a bug, and putting the newer numbers as a bug fix. Regression tests often go bit-by-bit instead of allowing for a certain tolerance (an example of this is TeX's famous test suite), but when those tests break the authors can look at the GSL release notes, and update their ground truth to the new values. This is the same thing people have to do with bit-by-bit regression tests when "non-physical-constant" bugs get fixed. And of course there's an xkcd: https://xkcd.com/1172/
physical constants that might need updating
I happened to come across a definition of the gravitational constant, which we have as: usr/include/gsl/gsl_const_cgs.h:#define GSL_CONST_CGS_GRAVITATIONAL_CONSTANT (6.673e-8) /* cm^3 / g s^2 */ /usr/include/gsl/gsl_const_cgsm.h:#define GSL_CONST_CGSM_GRAVITATIONAL_CONSTANT (6.673e-8) /* cm^3 / g s^2 */ /usr/include/gsl/gsl_const_mksa.h:#define GSL_CONST_MKSA_GRAVITATIONAL_CONSTANT (6.673e-11) /* m^3 / kg s^2 */ /usr/include/gsl/gsl_const_mks.h:#define GSL_CONST_MKS_GRAVITATIONAL_CONSTANT (6.673e-11) /* m^3 / kg s^2 */ and the one I saw was different: 6.67430 m^3/(kg*s^2). Looking it up, it turns out that since 1998 (when our number was valid), the measurement has been updated. You can see the history of updates at: https://en.wikipedia.org/wiki/Gravitational_constant#Modern_value and indeed the most recent is 6.67430. We might want to do an audit to make sure that we follow the NIST or LBL or another standards body on *all* the physical constants, since you want to update them in lockstep to make sure that some identities still apply. Our constants were introduced around 2000 and have not been touched since some additions in 2006. At the same time we might want to do a bit of soul searching on where our cutoff is for accepting constants into GSL. I do some work with earth parameters, and am shocked at the lack of a clear reference set of C header files (from NASA or whoever) with earth constants. gsl currently has fundamental constants (boltzmann, gravitational, bohr radius, electron charge, ... But we also have some more solar-system bound ones, like the astronomical unit, and we even reach pedestrian earth with things like GSL_CONST_MKSA_GRAM_FORCE which relates to the acceleration of gravity on the earth's surface. In fact we also have GSL_CONST_MKSA_GRAV_ACCEL, which is 9.80665 m/s^2. So I'd like to propose that we add a suite of earth radius values based on concepts from: https://en.wikipedia.org/wiki/Earth_radius#Global_average_radii https://gis.stackexchange.com/questions/25494/how-accurate-is-approximating-the-earth-as-a-sphere and fact sheets like: https://nssdc.gsfc.nasa.gov/planetary/factsheet/earthfact.html (and the references they give) To start with the earth radius, The International Union of Geodesy and Geophysics (IUGG) defines various types of mean earth radius, and they tend to stem from the definition of earth equatorial radius A and earth polar radius B. Setting R1 might be enough to cover what most people need. A patch for the gravity constant and addition of the earth stuff I mentioned would be like below, and similar for mks, cgs, and cgsm. At this point I'm just proposing it as food for thought - there is no urgency, and it might be best to apply this patch when we have audited *all* the physical constants we use, and possibly documented their provenance. diff --git a/const/gsl_const_mksa.h b/const/gsl_const_mksa.h index 5d91d1ca..4c82e272 100644 --- a/const/gsl_const_mksa.h +++ b/const/gsl_const_mksa.h @@ -22,12 +22,15 @@ #define __GSL_CONST_MKSA__ #define GSL_CONST_MKSA_SPEED_OF_LIGHT (2.99792458e8) /* m / s */ -#define GSL_CONST_MKSA_GRAVITATIONAL_CONSTANT (6.673e-11) /* m^3 / kg s^2 */ +#define GSL_CONST_MKSA_GRAVITATIONAL_CONSTANT (6.67430-11) /* m^3 / (kg s^2) */ #define GSL_CONST_MKSA_PLANCKS_CONSTANT_H (6.62606896e-34) /* kg m^2 / s */ #define GSL_CONST_MKSA_PLANCKS_CONSTANT_HBAR (1.05457162825e-34) /* kg m^2 / s */ #define GSL_CONST_MKSA_ASTRONOMICAL_UNIT (1.49597870691e11) /* m */ #define GSL_CONST_MKSA_LIGHT_YEAR (9.46053620707e15) /* m */ #define GSL_CONST_MKSA_PARSEC (3.08567758135e16) /* m */ +#define GSL_CONST_MKSA_EARTH_EQUATORIAL_RADIUS_A (6378137.0) /* m */ +#define GSL_CONST_MKSA_EARTH_POLAR_RADIUS_B (6356752.3) /* m */ +#define GSL_CONST_MKSA_EARTH_MEAN_RADIUS_R1 ((2*GSL_CONST_MKS_EARTH_EQUATORIAL_RADIUS_A + GSL_CONST_MKS_EARTH_POLAR_RADIUS_B) / 3.0) /* m */ #define GSL_CONST_MKSA_GRAV_ACCEL (9.80665e0) /* m / s^2 */ #define GSL_CONST_MKSA_ELECTRON_VOLT (1.602176487e-19) /* kg m^2 / s^2 */ #define GSL_CONST_MKSA_MASS_ELECTRON (9.10938188e-31) /* kg */
Re: Checking GSL for Spectroscopy
>I looked into this (the GNU doc on this is LONG!) but it is my > understanding that the GNU GPL can be used for commercial purposes. Yes, it can be used for commercial software, but never for proprietary software. So you will need to offer end users (for your *entire* derived work) the same freedoms that you received with the GNU Scientific Library. The simplest (and almost universal) way to do that is to license your resulting program under the GPL.
Re: Checking GSL for Spectroscopy
> I also need to be sure that a language (e.g. GSL) [...] Like others I'm delighted to hear of your interest in GSL, but I do need to point out that GSL is *not* a language -- it's a library of routines that can be called from various languages. The most natural is C, but most widely used VHLLs have GSL bindings. GSL's first release was in 1996, and it continues to have solid use, so you don't need to worry about longevity there. And the longevity of C code is extreme: the C standards committee is very careful about not disrupting the possible use of old code. As an example, I recently rebuilt GSL code from 20 years ago and it required almost no effort.
Re: Compling Error gsu 2.6
Dear Benedict, You do not mention what operating system you are on, and you don't say very much about what path you installed to. So there might be the need for a bit more, but you should be able to use the instructions here: https://www.gnu.org/software/gsl/doc/html/usage.html#compiling-and-linking I note that you did a single instruction to compile and link, while the documentation shows separate ones. That means that you should put the link instructions in your single command. You could try: g++ -I ../gsl-2.6 blub.cpp -o blub -L../gsl-2.6/lib -lgsl -lgslcblas -lm Note that I made the guess that your libraries were installed in ../gsl-2.6/lib, but I really don't know if that's where they are. You should use the -L option to point to where files like libgsl.so and libgslcblas.so are located.
Re: GSL - GNU Scientific Library for Mac
Charlotte, thanks for using GSL! I agree with those who suggest using a gnu/linux distribution for all computing, and especially for scientific software development. But if you are stuck with macos then there are a few packaging systems that offer GSL. The two most used proper packaging systems on macs are homebrew, where you will find: https://formulae.brew.sh/formula/gsl and macports, where you will find: https://ports.macports.org/port/gsl/summary But also note that these packaging systems are barely needed for gsl because we have designed it to have minimal requirements. You should be able to download the source tarball from https://www.gnu.org/software/gsl/ and follow the instructions in the INSTALL file: it's the usual "./configure" and "make -j n_cores install" procedure. If your own program still does not find the GSL header files then you will need to get comfortable with the compiler -I flag to specify the directory in which you installed GSL's headers, and the linker's -L flag to tell it where the libraries were installed. Since details of compiling might be noise on this list, feel free to write individual email once it gets down to those details.
Re: [Help-gsl] latest version of GSL available for Red Hat
Alan> You might have better luck asking on a RHEL or CentOS list. In Alan> the repos I have enabled, I only see 1.15 is available That's correct, and it's an embarrassment for them. Sadly the EPEL people don't package a newer version either. Maybe one from our lest could try to work with them on that. In my work this causes real problems: I release a huge simulation framework by building some 20 RPMs, and they need a newer GSL than 1.15. At first I made my own packages, but then they got in the way of other packages on Red Hat 7, so I had to create a differently named package (I called it gsl2_diorama, since our framework is called diorama) that installs in a different area (a bit like how Red Hat packages newer versions of the root C++ libraries). A lot of work to get that going, although it's made a bit easier by the careful use of autotools and of things like pkg-config and gsl-config.
Re: [Help-gsl] problems after installation of gsl
Jerzy> [...] I don't have any 'libgsl.so' or 'libgsl.a' in Jerzy> /usr/local/lib. Can you give me examples of what could I have Jerzy> done wrong? I just did your exact steps (on ubuntu 18.04 in this case; I'll try it later on my debian and red hat systems): download, ./configure; make -j; make install) and when I type: $ find /usr/local -name '*gsl*so*' I get this: $ find /usr/local -name '*gsl*.so*' /usr/local/lib/libgslcblas.so.0 /usr/local/lib/libgsl.so /usr/local/lib/libgsl.so.23 /usr/local/lib/libgslcblas.so.0.0.0 /usr/local/lib/libgslcblas.so /usr/local/lib/libgsl.so.23.1.0 $ Could you run find /usr/local -name '*gsl*.so*' on your system and send that to me? Also can you report if the "make install" step exited cleanly or with an error status? One way to find out is to look carefully at the output; another is to type echo $? first thing *immediately* after the "make install". You could also run: ./configure make -j YOUR_NUMBER_OF_CORES make install 2>&1 | tee makei.out and send me your makei.out file.
