various fixes for matrix initialisation #305
Conversation
MS software -- I have yet to find a single instance where it's reliable :) |
We have to migrate from travis-ci.org to travis-ci.com, I did the migration, so if everything worked, we will see the travis build for future commits. |
| @@ -114,7 +114,7 @@ class SchwefelFunction | |||
| template<typename MatType = arma::mat> | |||
| MatType GetFinalPoint() const | |||
| { | |||
| MatType result(initialPoint.n_rows, initialPoint.n_cols); | |||
| MatType result(initialPoint.n_rows, initialPoint.n_cols, arma::fill::none); | |||
There was a problem hiding this comment.
Are there any plans to support specific value initialization in the constructor as well?
There was a problem hiding this comment.
I've done preliminary experiments on this in an experimental armadillo branch. It seems to work, but the implementation is convoluted and hacky.
The seemingly straightforward approach of simply specifying a value on the constructor via Mat<eT>(uword n_rows, uword n_cols, eT scalar_fill_value) is actually not intuitive, could be confused with the cube constructor, and doesn't follow the arma::fill pattern. However it does allow using the eT template parameter directly to specify the correct type of the scalar.
A more intuitive approach (from a user perspective) is to have a constructor along these lines: mat(n_rows, n_cols, fill::value(123.0)). The problem here is that we can't constrain the type of the scalar, as the definition of fill::value() is separate from the definition of mat. In the experimental code I opted to use Mat<eT>( uword n_rows, uword n_cols, fill::scalar_holder<scalar_type>& f ), where scalar_type is a separate template parameter, and fill::scalar_holder<scalar_type> is generated via arma::fill(scalar_value). Then the scalar specified by the user is internally converted to the eT element type of the matrix. I'm not 100% certain that all the possible conversions are valid and/or portable across compilers.
There was a problem hiding this comment.
Could SFINAE work here, to ensure that whatever the provided scalar type is is castable to eT? It might also be possible to write an SFINAE overload where, when the scalar type cannot be converted to eT, a static_assert() is thrown. But, I am not sure if such complexity is warranted for that feature.
There was a problem hiding this comment.
@rcurtin Turns out a specific type of SFINAE in combination with a conversion operator did indeed help :) Gory details at the Gitlab repo.
Mainly to take into account changes in Armadillo 10.5, where matrices are by default constructed with all elements set to zero.
The changes in this PR are backwards compatible with earlier versions of Armadillo.