>The methods normalize_rows(), normalize_columns(), the function
cos_angle(), and the "norm" methods (esp. array_two_norm() and

>frobenius_norm()) should indeed not be instantiated for most "exotic" types (including std::complex and vnl_rational): this is imho kind of a

>design mistake. (Those functions could be provided outside of vnl_matrix, e.g. in vnl/algo/vnl_matrix_manipulations.*, and only for numeric

>types double and float. one_norm() and inf_norm() also make sense for int & vnl_rational etc. but not for e.g. polynomials.)

Moving the matrix operations to a separate file would allow many to be implemented in a templated manner, thus only someone who actually called that function on their type would see the error.

For example, template<class T> T one_norm(vnl_matrix<T> m){...} would only get instantiated when someone tried to use it. The function documentation could specify what operations need to be implemented on T for one_norm to work. People who never call one_norm would never need to know about it.

>Actually, a polynomial type T *should* be supported for vnl_matrix<T>.

>I'd propose to modify the vnl_matrix (and related) classes to make this work (almost) out-of-the-box.

>This should be discussed to a broader extent on this list, I believe.

The main problem with doing this is backward compatibility. I'd think matrix would be a widely used class. Changing its interface would mess up a lot of people's code.

Maybe the old matrix class could be put in vnl/vnl_matrix_deprecated.h so that people who have problems can just quickly go through their code and with search-and-replace to have everything working again? The header file could print a warning "Warning vnl_matrix_deprecated will be removed in the next vxl release" on the compilers that support it. The deprecated class could be declared as a subclass of vnl_matrix so that it can be passed to all functions requiring a matrix. Then at the next major version release (when interfaces are expected to change) the vnl_matrix_deprecated class can be removed.

>frobenius_norm()) should indeed not be instantiated for most "exotic" types (including std::complex and vnl_rational): this is imho kind of a

>design mistake. (Those functions could be provided outside of vnl_matrix, e.g. in vnl/algo/vnl_matrix_manipulations.*, and only for numeric

>types double and float. one_norm() and inf_norm() also make sense for int & vnl_rational etc. but not for e.g. polynomials.)

Moving the matrix operations to a separate file would allow many to be implemented in a templated manner, thus only someone who actually called that function on their type would see the error.

For example, template<class T> T one_norm(vnl_matrix<T> m){...} would only get instantiated when someone tried to use it. The function documentation could specify what operations need to be implemented on T for one_norm to work. People who never call one_norm would never need to know about it.

>Actually, a polynomial type T *should* be supported for vnl_matrix<T>.

>I'd propose to modify the vnl_matrix (and related) classes to make this work (almost) out-of-the-box.

>This should be discussed to a broader extent on this list, I believe.

The main problem with doing this is backward compatibility. I'd think matrix would be a widely used class. Changing its interface would mess up a lot of people's code.

Maybe the old matrix class could be put in vnl/vnl_matrix_deprecated.h so that people who have problems can just quickly go through their code and with search-and-replace to have everything working again? The header file could print a warning "Warning vnl_matrix_deprecated will be removed in the next vxl release" on the compilers that support it. The deprecated class could be declared as a subclass of vnl_matrix so that it can be passed to all functions requiring a matrix. Then at the next major version release (when interfaces are expected to change) the vnl_matrix_deprecated class can be removed.