#67 const correctness in Sparse_Vec<T>

itpp (51)
David Hammarwall

In the current implementation of sparse vectors, it is difficult to use the svec class using constant references which is a problem if you write code that try to comply with the const correctness coding style.

The problem arise because of the lack of const versions of the member functions:

double Sparse_Vec<T>::density();
int nnz();
void get_nz_data(int p, T& data_out);
T get_nz_data(int p);
ivec get_nz_indices();

That is, the lack of:
double Sparse_Vec<T>::density() const;
int nnz() const;
void get_nz_data(int p, const T& data_out) const;
T get_nz_data(int p) const;
ivec get_nz_indices() const;

I get that the problem arise because each of these functions call the non-const function remove_small_elements() in case the check_small_elems_flag is set.

In the end I guess it's all about how to interprete elements less then epsilon. In my (humble) opinion, elements less than epsilon should allways be interpreted as zero - thus, the objective state is unchanged when the remove_small_elementes() function is called. This off-cource has the implication that an output function must ensure that an element less than epsilon is never returned...

With this mindset, remove_small_elements(), can be interpreted as a const function, and the affected member variables should be mutable... (including data, check_small_elems_flag, and used_size)


  • Logged In: YES
    Originator: NO

    Hi David,

    Thanks for your post and sorry for not replying to it earlier.
    Unfortunately, I am not familiar with the implementation of Sparse_Vec and Sparse_Mat classes. Anyway your suggestions sound reasonable. You are welcome to improve Sparse_Vec (and maybe Sparse_Mat too). To do so, please provide a patch against the latest trunk sources with short description of changes in the ChangeLog file.


    PS. You can also contact Mark Dobossy (mdobossy at users.sourceforge.net), who was working on a new implementation of Sparce_Vec and Sparce_Mat classes for inclusion in IT++. Unfortunately, Mark's implementation is not yet included in the library.