gsl_vector_alloc_from_vector

gsl_vector_alloc_from_vector

[Sebastian Tannert]

Hello,

is the function: gsl_vector_alloc_from_vector

still future part of the GSL or depreciated.

Thanks a lot!

Sebastian

---------------------------
DP Sebastian Tannert  / tannert@physik.hu-berlin.de / 030/2093 7951

Humboldt Universit"at Berlin / Institut f"ur Physik / AG Photobiophysik
Newtonstrasse 15 / D-12489 Berlin-Adlershof

Version Problem

[Carlo Ferrigno]

Upgrading from version 1.3 to 1.4 I noticed the definition of physical 
constant has changed.

1) the file gsl_const.h does not include the right files and gives an error
2) the constant are named in a different way. This does not allow to compile a 
programme built for 1.3 with gsl 1.4 and vice versa.

Do you have any suggestion to overcome the problem without rewriting the code, 
for example with a preprocessing set of commands ?

thank you,

carlo

-- 
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Carlo Ferrigno
Universita` degli studi di Palermo &
Istituto di Astrofisica Spaziale (IASF) 
via Ugo La Malfa 153
90146 Palermo
Italy
	phone		+39.091.6809624
	mobile		+39.333.3599421										
E-mail:    ferrigno@pa.iasf.cnr.it
///////////////////////////////////////////////

Re: Version Problem

[Brian Gough]

Carlo Ferrigno writes: Upgrading from version 1.3 to 1.4 I noticed the
 > definition of physical constant has changed.
 > 1) the file gsl_const.h does not include the right files and gives
 > an error 
 > 2) the constant are named in a different way. This does
 > not allow to compile a programme built for 1.3 with gsl 1.4 and
 > vice versa.  Do you have any suggestion to overcome the problem
 > without rewriting the code, for example with a preprocessing set of
 > commands ?
 > 

I messed up gsl_const when I made the 1.4 release (I'm sorry).  It is
broken.

If you have both versions installed you can try something like this,

   gcc -I/opt/gsl-1.4/include -I/opt/gsl-1.3/include ....

or use the C_INCLUDE_PATH environment variable.

I will try to fix it all in 1.5, so it is smoothly backwards compatible.

An alternative is to ship the appropriate files (e.g. gsl_mks.h and
gsl_cgs.h) with your source in such a way that they are included
(e.g. in a gsl/ subdirectory).  Note that the cgs electrical constants
in 1.3 were incorrect (missing factor of 4pi)

-- 
Brian Gough

Re: Version Problem

[Brian Gough]

Brian Gough writes:
 > Carlo Ferrigno writes: Upgrading from version 1.3 to 1.4 I noticed the
 >  > definition of physical constant has changed.
 >  > 1) the file gsl_const.h does not include the right files and gives
 >  > an error 
 >  > 2) the constant are named in a different way. This does
 >  > not allow to compile a programme built for 1.3 with gsl 1.4 and
 >  > vice versa.  Do you have any suggestion to overcome the problem
 >  > without rewriting the code, for example with a preprocessing set of
 >  > commands ?

This should now be fixed in CVS (and will be in the next release, with
backwards compatibility for the mks/cgs and mksa/cgsm header files).

-- 
Brian Gough

Re: gsl_vector_alloc_from_vector

[Brian Gough]

Sebastian Tannert writes:
 > Hello,
 > is the function: gsl_vector_alloc_from_vector
 > still future part of the GSL or depreciated.


The function is deprecated (but will stay in the library until 2.0 for
backwards compatibility).

The gsl_vector_view object provides a better way to access/manipulate
subvectors.

best regards
-- 
Brian Gough

Re: gsl_vector_alloc_from_vector

[Brian Gough]

Carlo Perassi writes:
 > > The function is deprecated (but will stay in the library until 2.0 for
 > 
 > hi
 > your statement makes me wonder: do you have a roadmap to 2.0?

Not specifically. 

There are a number of things that I would like to change, but that
break backwards compatibility,  so I can't make them in 1.x.

Such as,

- make ranlux the default generator

- fix the printf functions to use the parameter order (fmt, args) not
(arg, fmt) as for normal printf

- fix some auxiliary functions (in multifit) which have inconsistent
parameter ordering

Possibly these changes just for consistency are not worth the trouble
though.

-- 
Brian Gough

Re: gsl_vector_alloc_from_vector

[Brian Gough]

Sebastian Tannert writes:
 > Hm, but as far as I've seen the vector view concept
 > just covers the same stuff inside a new struct.
 > Is there any advantage beside having two distinct data types?
 > 
 > In a first look it only seems to make using vector views
 > more complicated and to take more time for another 
 > step in accessing the data from memory.

The advantage of views is that they make clear which objects own the
underlying memory of the vector data and are responsible for
deallocating it.  Vectors always have ownership of the data, views
never do.

In the previous method, where there was only the vector type, it was
not possible to distinguish between the two cases so easily (that was
a long time ago though).

I don't think views any significant performance disadvantage.  Since
they are allocated on the stack they can be more efficient than some
of the old vector-style usage of malloc that was originally needed.

-- 
Brian Gough