Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Peter Vanroose <peter_vanroose@ya...>  20090711 09:03:50

Eric, You're of course right. In this respect, vnl_matrix and vnl_vector could be (1) better documented, and (2) made somewhat less dependent on unnecessary stuff (like isnan). Do you think there should be a named form for additive_identity and multiplicative_identity (e.g. in numeric_traits<T>) instead of using T(0) and T(1) ? I would vote for the "automatic cast from int" and keep T(0) and T(1) as required by the "numeric" class. But the "spirit" of the documentation is correct: with minimal commonsense assumptions, one can use any numeric type of his/her own to build a vnl_matrix on. Have e.g. a look at vnl/vnl_bignum.h , vnl/vnl_bignum_traits.h , vnl/vnl_rational.h , vnl/vnl_rational_traits.h for an example of two classes from which a vnl_matrix can be (and are) built.  Peter.  __________________________________________________________ Ta semester!  sök efter resor hos Kelkoo. Jämför pris på flygbiljetter och hotellrum här: http://www.kelkoo.se/c169901resorbiljetter.html?partnerId=96914052 
From: Peter Vanroose <peter_vanroose@ya...>  20090711 16:07:52

> ... square root (required by the cosine angle function) is not > well defined, so rational functions would not qualify as a > contained type. Squareroot is actually not welldefined for > several of the types used in matrices, however, because of > the automatic conversion to double, this is not noticed. Agreed. 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.) 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) outofthebox. This should be discussed to a broader extent on this list, I believe.  Peter.  __________________________________________________________ Går det långsamt? Skaffa dig en snabbare bredbandsuppkoppling. Sök och jämför priser hos Kelkoo. http://www.kelkoo.se/c100015813bredband.html?partnerId=96914325 
From: Eric Moyer <eric_moyer@ya...>  20090711 17:30:26
Attachments:
Message as HTML

>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) outofthebox. >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 searchandreplace 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. 
From: Eric Moyer <eric_moyer@ya...>  20090711 15:20:17
Attachments:
Message as HTML

>Do you think there should be a named form for additive_identity and multiplicative_identity (e.g. in numeric_traits<T>) >instead of using T(0) and T(1) ? I would vote for the "automatic cast from int" and keep T(0) and T(1) as required by >the "numeric" class. I think that there already is a named form: the members zero and one. I understood from the comments that these were to be the additive and multiplicative identities. Thus, seeing that one already had to define the additive and multiplicative identities, it seemed wrong to ignore them and use a cast from integer. Even though additive_identity and multiplicative_identity are more general, I think that the vast majority of users will be well served by T(0) and T(1), suitably documented. In computer vision it is very rare to need to make a matrix of some kind of exotic group where T(0) is not additive identity. It may not be not wise to try for the whole generality, it just adds more complexity and more chance for bugs. I was originally looking at this because I thought I wanted a matrix of polynomials. I have since realized that I was completely wrong and not thinking about my problem correctly. However, this gives a kind of benchmark into how far a the matrix class can be pushed. Polynomials can be considered as a kind of numeric type, having addition, subtraction, multiplication and limited division. If you allow rational functions, you can get full division, a field with +,,*,/. Even in this case T(0) and T(1) would work. However, square root (required by the cosine angle function) is not well defined, so rational functions would not qualify as a contained type. Squareroot is actually not welldefined for several of the types used in matrices, however, because of the automatic conversion to double, this is not noticed. ________________________________ From: Peter Vanroose <peter_vanroose@...> To: Eric Moyer <eric_moyer@...> Cc: vxlusers mailing list <vxlusers@...> Sent: Saturday, July 11, 2009 5:03:47 AM Subject: Re: vnl_matrix documentation is incorrect re: methods of contained type Eric, You're of course right. In this respect, vnl_matrix and vnl_vector could be (1) better documented, and (2) made somewhat less dependent on unnecessary stuff (like isnan). Do you think there should be a named form for additive_identity and multiplicative_identity (e.g. in numeric_traits<T>) instead of using T(0) and T(1) ? I would vote for the "automatic cast from int" and keep T(0) and T(1) as required by the "numeric" class. But the "spirit" of the documentation is correct: with minimal commonsense assumptions, one can use any numeric type of his/her own to build a vnl_matrix on. Have e.g. a look at vnl/vnl_bignum.h , vnl/vnl_bignum_traits.h , vnl/vnl_rational.h , vnl/vnl_rational_traits.h for an example of two classes from which a vnl_matrix can be (and are) built.  Peter.  __________________________________________________________ Ta semester!  sök efter resor hos Kelkoo. Jämför pris på flygbiljetter och hotellrum här: http://www.kelkoo.se/c169901resorbiljetter.html?partnerId=96914052 