Boost logo

Boost :

From: Stefan Koch (maillist_at_[hidden])
Date: 2005-04-26 19:51:52

Toon Knapen <toon.knapen_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 hardcoded IMHO.

Actually the ones I an aware of are of the form ( sum |x_i|^p )^(1/p).

With p = 2 this is the most common case (especially for 3-D vectors)
as given above. It can also be easily reformed (as above) to make
sure there is no intermediate overflow. This is sometimes is called
the length (especially for 3-D Vectors). Unfortunately the length of
a generic vector already means the number of elements, so that is not
a good name.

I is certainly possible to overload the norm member function to take
an additional argument for p.

> > 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.

And also outer product r_{i,j} = x_i * y_j. But, this is probably the
least useful of them all.

But, you bring up a good point. Should the 3-D vector class
(implicitly) support vectors with complex coordinates. Certainly this
should be the case for a general n-dimensional vector. For a 3-D
vector specifically targeted for geometrical rotations and reflections,
I do not think this is appropriate.

> > 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
> > function.
> 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* ?

I could not agree more. That is why I did not define the * operator
for two vectors.

Boost list run by bdawes at, gregod at, cpdaniel at, john at