ccgsl-announce Mailing List for ccgsl
Use Gnu Scientific Library as if it were writtem in C++.
Brought to you by:
jdl3
You can subscribe to this list here.
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: John D L. <j.d...@jo...> - 2021-06-07 16:20:44
|
This version covers gsl-2.7, which was recently released. There are only small changes from version 2.6.5, to cover a small amount of extra functionality in gsl-2.7. John D Lamb |
From: John D L. <J.D...@jo...> - 2020-09-06 16:40:39
|
This version fixes a bug that could cause small memory leaks (typically four bytes). -- John D Lamb |
From: John D L. <J.D...@jo...> - 2020-05-30 06:04:24
|
This version of ccgsl covers just about everything in GSL 2.6. It omits a few features, like sorting, that are natively handled in C++. All the function structs in GSL can now be constructed from function objects. Nothing in ccgsl needs to be allocated using malloc() or free() functions and where a GSL function takes an array as an argument (eg double[]) you can pass a std::vector, std::array or gsl::vector instead. -- John D Lamb |
From: John D L. <J.D...@jo...> - 2020-04-08 17:47:30
|
I’ve just released a new version of CCGSL covering version 2.6 of the Gnu Scientific Library. There is quite a bit of new code here. As usual, it wraps GSL functions using only C++ header files. There is no library and code built with CCGSL should compile except with much older C++ compilers. The code can still be improved quite a bit. Here are some of the things that have been done. 1. The code allows you to create anything that requires a GSL alloc() function to be created as a reference class (a bit like a std::shared_ptr) so we don’t ever have to remember to free and object: free() is called when there are no more references to an object. 2. Most functions are embedded in namespaces, allowing you to use shorter names. The naming convention is consistent with GSL except in a few cases where that would create a conflict. 3. Most functions have at least minimal documentation, though a few are not even documented in the current GSL manual. 4. Where a GSL function expects a pointer to a GSL struct, you can nearly always pass an object constructed as in 1 above. Here are some things that could be done (feel free to volunteer to help). 1. Several GSL functions expect pointers to C functions. But in C++ we want to be to pass function objects instead. In only a few cases have I managed to implement this. 2. There are some inconsistencies in how CCGSL translates GSL functions to either namespace functions, static class functions (for practical purposes nearly indistinguishable from namespace functions) and member functions. Generally I have tried to use member functions only when they are essential or the most obvious place to implement the GSL equivalent. Sometimes CCGSL has both a member function and a static class function. But improvements and additions would help. 3. There are some inconsistencies in handling of pointers to non-class types. Typically CCGSL does this by reference so that the user can see the difference between where, for example, a double is wanted rather than an array of doubles. Here are things that CCGSL does not currently plan to do (but feel free to say otherwise and help do them if it makes sense). 1. CCGSL avoids operator overloading for adding and multiplying matrices, vectors and the like. 2. CCGSL does not include any code that needs to be compiled and installed as a library. -- John D Lamb |
From: John D L. <J.D...@bt...> - 2012-08-26 16:06:17
|
This version is mainly designed to allow you to drop stride arguments in functions where an array parameter is required. For example, C++ overloading allows us to create gsl::mean( double comnst* array, size_t stride, size_t size ) and gsl::mean( double const* array, size_t size ) functions. Clearly the second is easier to work with, and gsl::mean( std::vector<double> const& array ) and gsl::mean( gsl::vector const& array ) are even easier to work with. In the course of updating these functions, I’ve detected and corrected a few obscure bugs, mainly in the weirder statistics functions that act on integer arrays. I’ve also changed the permutation functions to make them a bit more natural for C++ users and to provide wrappers for permutations acting on arrays other than gsl::vector objects. -- John D Lamb |
From: John D L. <J.D...@bt...> - 2012-08-25 14:58:54
|
This is version 0.99-7 and contains minor additions and bug fixes over 0.99-4 – 0.00-6. There are three additions: 1. Overloaded functions for const_* functions in the vector classes. For example, if v is a gsl::vector const object, then v.subvector( i, n ) gives the same result as v.const_subvector( i, n ). This should make it easier to write code using the same (overloaded) function for const and non-const objects. 2. real() and imag() vector (view) functions for the vector_complex classes. 3. Bidirectional iterators for the matrix classes. These allow you to write expressions like the following in C++11: for( row : matrix ){ … } Inside the for loop row is a vector containing a row of matrix. This is more expressive but marginally less efficient than using for( size_t row_index = 0; row_index < matrix.size1(); ++row_index ){ … } together with the matrix.get() and matrix.set() functions. There is one bug fix, which applies to some of the block, vector and matrix classes. It prevents the destructor of a default-constructed object from trying to decrement a null pointer. In practice, the objects should nearly always be constructed with one or two size parameters, even if these parameters are zero. -- John D Lamb |
From: John D L. <J.D...@bt...> - 2012-08-15 17:01:25
|
This is now available from http://ccgsl.sourceforge.net/index.php -- John D Lamb |