>Do you think there should be a named form for additive_identity and
multiplicative_identity (e.g. in numeric_traits<T>)
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. Square-root is actually not well-defined for several of the types used in matrices, however, because of the automatic conversion to double, this is not noticed.
From: Peter Vanroose <email@example.com>
To: Eric Moyer <firstname.lastname@example.org>
Cc: vxl-users mailing list <email@example.com>
Sent: Saturday, July 11, 2009 5:03:47 AM
Subject: Re: vnl_matrix documentation is incorrect re: methods of contained type
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 common-sense 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.
Ta semester! - sök efter resor hos Kelkoo.
Jämför pris på flygbiljetter och hotellrum här:http://www.kelkoo.se/c-169901-resor-biljetter.html?partnerId=96914052