From: Eric Moyer <eric_moyer@ya...>  20090711 15:20:17

>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 