Boost logo

Boost :

From: Stefan Koch (maillist_at_[hidden])
Date: 2005-04-25 20:21:53


"Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]> writes:

> > Any interest in a templatized class for 3-Dimensional vectors?
> > (Similar in style to std::complex or boost math/octonion and
> > math/quaternion.)
>
> FYI: A few years ago I put together cooperating classes for 3-dim vectors,
> 3x3 matrices and 3x3 symmetric matrices (storing only the six unique elements):
>
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/vec3.h?view=markup
>
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/mat3.h?view=markup
>
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/sym_mat3.h?view=markup
>
> See also: http://cctbx.sourceforge.net/
>

Thanks for the information and link. That is an interesting class
with lots of functionality. In contrast my class is much more focused
on providing just an interface for a 3D vector ADT as needed (for
example) in a physics problem. I think this makes it easier and in at
least one case safer to use. I also believe that this simplicity
makes it more appropriate for inclusion into boost, and for
standardization.

Specific examples of where your class seems to have extra
functionality that I do not think is appropriate for a 3D vector ADT
include the each_update_min/each_update_max, and the sum, and product
methods. I cannot think of a context where these would be used on a
3-Dimensional vector. (They seem to be more useful for a general
purpose n-dimensional vector.)

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.

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.

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.

Feel free to look at my implementation. It is available at
    http://isolda.com/vector3/index.html

Stefan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk