Gsl_vector_const_view

I think the way const's are dealt with in gsl_vector_views (and matrix
views) is possibly flawed.  If it's not flawed I'm missing something
fundamental in the way they are intended to  be used.

The gsl_vector_const_view is currently just implemented as a const
gsl_vector_view (which I'm sure was the easiest way to do it that works
in most cases).  While this forces the vector member to be const, it
means that the block pointer becomes a const pointer to non-const data
("gsl_block* const block" when I think we want "const gsl_block*
block"?).  This means there is nothing actually protecting the data
itself other than the const wrapper being interpreted by functions that
are designed to take gsl_vector*s as inputs.

As a demonstration of the problem consider:

  const double data1[] = {1, 2, 3, 4};
  const double* data2;

  data2 = data1;    //This is appropriately legal

  // Clearly these will not work:

  // data1[0] = 10;

  // data2[0] = 10;

  gsl_vector_const_view A = gsl_vector_const_view_array(data2, 4);

  // constness keeps this from working:
  // gsl_vector_set(&A.vector, 0, 10);

Re: Gsl_vector_const_view

At Mon, 4 Dec 2006 17:21:09 -0800,
Leibs, Jeremy wrote:
> I think the way const's are dealt with in gsl_vector_views (and matrix
> views) is possibly flawed.  If it's not flawed I'm missing something
> fundamental in the way they are intended to  be used.

Hello,

Thanks for your email.  You're correct that the const does not protect
the data, only the struct.  Ideally it would protect the data as well
but I couldn't find a reasonable way to do that.

Originally I tried having a const inside the struct, similar to your
example, but it made the const and non-const versions of the
gsl_vector type incompatible.

This meant that it wasn't possible to have functions which accepted
both const and non-const vectors, as it would be for normal C library
functions (e.g. strlen).  I was surprised that it was not possible but
could not find any way round it in the C standard.  A simple program
which shows the problem is attached below. 

So the best scheme that I could come up with was the current one,
which protects const vectors from being passed to gsl functions that
would modify them, if not from direct modification.

--

-- 
Brian Gough
(GSL Maintainer)

gsl_ran_flat: bug or improper usage ?

I seem to be getting some strange results when I use gsl_ran_flat on some 
systems (and not on other systems). The attached bash script extracts a c 
program, compiles it and runs it twice: once using gsl_rng_uniform and then 
using gsl_ran_flat. In the case where gsl_ran_flat is used, the value gamma, on 
some systems, comes out as nan, and on other systems comes out as 1 (as it 
should be).

Here are the results I get with Fedora:

> gcc -g gsl_ran_flat.c -L/usr/lib -lgsl -lgslcblas -lm -o gsl_ran_flat
> ./gsl_ran_flat uniform
gamma = 1.000000
> ./gsl_ran_flat flat
gamma = nan
> gsl-config --version
1.7
> uname -sr
Linux 2.6.17-1.2174_FC5
> rpm -q gsl
gsl-1.7-1.2.1
> cat /etc/redhat-release
Fedora Core release 5 (Bordeaux)

Here are the results I get with Cygwin

> gcc -g gsl_ran_flat.c -L/usr/lib -lgsl -lgslcblas -lm -o gsl_ran_flat
Info: resolving _gsl_rng_default by linking to __imp__gsl_rng_default 
(auto-import)
> ./gsl_ran_flat uniform

Re: gsl_ran_flat: bug or improper usage ?

Brad Bell wrote:
> 
> I seem to be getting some strange results when I use gsl_ran_flat on 
> some systems (and not on other systems). The attached bash script 
>
> # include <stdio.h>
> # include <gsl/gsl_rng.h>
> # include <string.h>

Hello,

I think you just have a missing header file (gsl_randist.h) for that 
function. Use gcc -Wall to detect that.

--

-- 
best regards,

Brian Gough
(GSL Maintainer)

Network Theory Ltd,
Publishing the GSL Manual - http://www.network-theory.co.uk/gsl/manual/

Please run these programms.

Hi,
I don't know, it's bug or it's my mistake.
I'm sending now three programms.  The output is buggy.

Thanks for taking the time.

Regards

Andrzej Buczynski

Moosburg, Germany

//   check of inversion of real unity matrix UNITY
#include <stdio.h>
#include <math.h>
#include <gsl/gsl_matrix.h>
#include <gsl/gsl_linalg.h>
#include <gsl/gsl_blas.h>
#include <gsl/gsl_complex.h>
#include <gsl/gsl_complex_math.h>
#include <gsl/gsl_mode.h>
#include <gsl/gsl_permutation.h>
#include<gsl/gsl_permute_complex_double.h>
#include <gsl/gsl_types.h>
#include <gsl/gsl_errno.h>
#include <gsl/gsl_check_range.h>
#include <gsl/gsl_vector_double.h>
#include <gsl/gsl_vector_complex.h>

memory problem

When I place the command 

 gsl_rng_free (r);  in line 43 , then comes out the memory segmantation
problem.

Bug, or my mistake?

Regards

Andrzej Buczynski

Moosburg, Germany

#include <stdio.h>
#include <gsl/gsl_matrix.h>
#include <gsl/gsl_linalg.h>
#include <gsl/gsl_blas.h>
#include <gsl/gsl_complex.h>
#include <gsl/gsl_complex_math.h>
#include <gsl/gsl_mode.h>
#include <gsl/gsl_permutation.h>
#include<gsl/gsl_permute_complex_double.h>
#include <gsl/gsl_types.h>
#include <gsl/gsl_errno.h>
#include <gsl/gsl_check_range.h>
#include <gsl/gsl_vector_double.h>
#include <gsl/gsl_vector_complex.h>
#include <gsl/gsl_block_complex_double.h>
#include <gsl/gsl_rng.h>

Re: Please run these programms.

buc-family <at> t-online.de wrote:
> Hi,
> I don't know, it's bug or it's my mistake.
> I'm sending now three programms.  The output is buggy.
> 
> Thanks for taking the time.
>  

Hello,

You can get help debugging your own program on the help-gsl <at> gnu.org 
list.  Please use the bug-gsl mailing list only for reporting actual 
bugs in GSL -thanks.  Note that you do need to call gsl_linalg_LU_decomp 
to decompose the matrix before calling any other functions.

--

-- 
Brian Gough
(GSL Maintainer)

Network Theory Ltd,
Publishing the GSL Manual - http://www.network-theory.co.uk/gsl/manual/

Re: gsl_ran_flat: bug or improper usage ?

Thanks Brian,
It was improper usage on my part.
Here is the result of compiling with -Wall:

[brad <at> dhcp-76-59 lib]$ ./gsl_ran_flat.sh
> gcc -g -Wall gsl_ran_flat.c -L/usr/lib -lgsl -lgslcblas -lm -o
gsl_ran_flat
gsl_ran_flat.c: In function main:
gsl_ran_flat.c:26: warning: implicit declaration of function gsl_ran_flat
> ./gsl_ran_flat uniform
gamma = 1.000000
> ./gsl_ran_flat flat
gamma = nan

Here is the result when the the statement
         # include <gsl/gsl_randist.h>
is added to the list of includes:

> gcc -g -Wall gsl_ran_flat.c -L/usr/lib -lgsl -lgslcblas -lm -o
gsl_ran_flat
> ./gsl_ran_flat uniform
gamma = 1.000000
> ./gsl_ran_flat flat
gamma = 1.000000

On Fri, 15 Dec 2006, Brian Gough wrote:

> Brad Bell wrote:
>> 

Electron charge units in gsl_const_cgsm.h

I think that the electron charge in gsl_const_cgsm.h should be
expressed in statcoulomb instead of coulombs. Coulombs is a MKS unit, not a
CGS unit.

http://en.wikipedia.org/wiki/Statcoulomb

In statcoulombs the charge of the electron is about 4.8e-10. 

Sébastien

Re: Electron charge units in gsl_const_cgsm.h

At Tue, 19 Dec 2006 13:08:44 -0500,
Sebastien Maret wrote:
> I think that the electron charge in gsl_const_cgsm.h should be
> expressed in statcoulomb instead of coulombs. Coulombs is a MKS unit, not a
> CGS unit.

Hello,

I believe the value in gsl_const_cgsm.h is correct, it is given in
abcoloumbs (abamp seconds) for the CGSM system.

--

-- 
best regards,

Brian Gough
(GSL Maintainer)

Network Theory Ltd,
Publishing the GSL Manual - http://www.network-theory.co.uk/gsl/manual/