From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-04-26 06:35:48
Stefan Koch wrote:
> "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]> writes:
> One place where I think the over general approach limits the class
> directly is in the length member function. You have this implemented
> as sqrt( x^2 + y^2 + z^2 ). The preferred way to implement this for
> vectors of floating point types is as m * sqrt( (x/m)^2 + (y/m)^2 +
> (z/m)^2 ) where m is max( x,y,z). This way there is no chance of
> internal overflow in the calculations when the components approach the
> limit of the floating point type used. Of course, if the vector type
> is also to be used with integers as the components (as I assume you
> support due to the presence of the % operator, and the comment of this
> class also supporting color representations) this trick does not work.
There are a million different ways to define a norm. It should be up to
the user to specify which norm he actually wants to use instead of being
> You also made an interesting design choice in allowing the * operator
> to be used as the dot product between two vectors. I choose not do do
> this, but to provide a non operator function of dot (much like cross
> for cross products). The reason for this is that there are three
> types of vector products that can be useful between two vectors x, y:
> 1. dot product r = sum x_i * y_i
> 2. element by element product r_i = x_i * y_i
> 3. cross product.
You forgot the inner product where: r = sum conjugate(x_i) * y_i.
> For generic vectors the cross product is not appropriate, but the first
> two are. The dot product of the obvious choice from a linear algebra
> standpoint. For generic n-dimensional vectors, it has been my
> experience that it is more common to want to element wise product.
> Matrix programs like maple and octave define two operators ( * and .* )
> to provide both. Numerical Python provides only the element wise
> product as an operator.
> For these reasons there did not seem to be an obvious choice for the *
> operator between two 3-D vectors, so I chose to make it a separate
And I think the inner-product is more appropriate '-). Just to say that
it rather depends on personal preference. The problem is that there are
not enough operators available but on the other side: is it necessary to
overload operator* ?
> Feel free to look at my implementation. It is available at
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk