From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-06-15 13:11:23
Michael Fawcett said: (by the date of Wed, 14 Jun 2006 13:16:12 -0400)
> I currently use enable_if and is_same from boost to determine what
> functions should be exposed. There are convenience functions like:
> as_array() to be used like glVertex3fv(my_vec.as_array());
> that only make sense if the vector contained all of the same type.
> Otherwise, in cases like vec3<float, short, float>, as_array() would
> be disabled. I suspect that we could do the same for the rest of the
> operations (dot_product, cross_product, etc).
in current design (see parent post) it is decided that all components of
vector/matrix/quaternion have the same underlying type (specified as
second template argument). IMO this is a good decision, because the main
goal here is to work with units (then math). And this most of the time
involves math, physics or engineering. With such target usage it makes
no sense to use different underlying types.
Examples that you have provided below are not from math, physics or
engineering field, so they do not apply here. It is possible that this
library will work in such scenarios, but this is not the design target.
Possible solutions are given below.
> On 6/14/06, Janek Kozicki <janek_listy_at_[hidden]> wrote:
> > Another question - would quaternions be something like vector<4,double> ?
> > For me it looks like a good idea. Template specialization can offer
> > category A operations that are specific to quaternions, when someone
> > works with unitless vector<4>.
> > It would be just like template specialization will provide cross product
> > for vector<3>, which is specific only for vector<3>.
> > Besides quaternions are also known to be used together with
> > matrix<4,4,double>.
> I don't think this is the correct thing to do. There are uses of
> vector<4> where quaternion operations don't make sense, but classic
> vector operations do.
> In graphics programming vector<4>s are sometimes used as the color
> component, with data encoded into each field to be used by a hardware
it is more like a tuple with four components. Of course storing them as
vector is handy, but there is not math inside, it's just a container for
> There are often times where the 'w' component is used to signal that
> the vertex is at infinity, but should otherwise still be treated as a
> classic vector<3>.
so it would be a vector<3> with a bool flag. Makes sense, because there
is no cross_product defined for vector<4> in which the last component is
some bool flag.
> For lights, the 'w' component is used to signal the type of light,
> directional or point (omni-directional). That type specifies how the
> x,y,z components should be interpreted. If the light is directional,
> then the x,y,z is a direction vector. If the type is a point light,
> the x,y,z components are a position in space.
so it's a vector<3> with an enum flag.
> I agree about the only allowing certain operations using template
> specialization for the vector/quaternion classes, but I disagree that
> quaternion can simply be vector<4> with the provided quaternion
> specializations. I think it should be a separate class following the
> same principles.
Your arguments did not convince me at all, because they are out of place.
Also - think about it - there is only one applicable definition of
multiplication between vector<3> and vector<4> - and this definition
will assume vector<4> to be quaternion which rotates vector<3>
Other definition for such multiplication doesn't exist, so there is no
conflict with other math fields. It's specific just like cross product
So still I think that quaternion can be a template specialization for
unitless (dimensionless) vector<4>. Also we can add a
typedef quaternion<double> vector<4,double>; // etc...
-- Janek Kozicki |
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk