
Boost : 
From: Stefan Koch (maillist_at_[hidden])
Date: 20050426 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 3D 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 3D 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 3D vector class
(implicitly) support vectors with complex coordinates. Certainly this
should be the case for a general ndimensional vector. For a 3D
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 ndimensional 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 3D vectors, so I chose to make it a separate
> > function.
>
>
>
> And I think the innerproduct 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk