Re: [boost] [PQS] scope of the library Quaternions and vector/matrix with units

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-06-17 19:23:18

Michael Fawcett said:     (by the date of Thu, 15 Jun 2006 15:28:08 -0400)

> > 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
> > data.
> 
> Sure, but often dot products are used on that data if the author knows
> it makes sense.  Why do you care what is stored in there as the
> library author?  The vector<4, float> (or whatever we are calling it
> now) may be the color component, but it may store a normal vector in
> the first 3 components with a texture lookup id in the last component.
>  Who cares if the author wants to say   normalize(myvec4.as_vec3());
> as long as the types in myvec4 allow normalize to function correctly.

You are assuming that there is a function in vector<4> that converts it
into vector<3> by dropping some undefined (random?) field. In fact such
operation makes little sense in linear algebra, if the user needs to do
that, he would better declare vector<3> and assign each field
individually, so that he can chose which field to be left out, and maybe
also to change the field order.

I'm against adding such function - it's too imprecise - sorry about that.

Also Geoffrey Irving in the same thread said that a similar conversion
between quaternion and vector<3> will confuse users a lot (and each user
could expect something different to be done), so better disallow it.
Quote follows:

Geoffrey Irving wrote:

> where v = (x,y,z) is canonically viewed as the quaternion (0,x,y,z).
> rotated_v will come out looking like (0,rx,ry,rz), so we can drop the
> zero and view it as a vector again.
> This could be a problem if the conversion between vector<3> and
> quaternion was an actual C++ conversion, since q * v could mean two
> completely different things.  I imagine most people handle this by
> disallowing that conversion.

 
> > > 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.
> 
> No, but again, why do you care?  The cross product IS defined for a
> vec<3> of all the same type, so the user will be able to use that if
> it makes sense.  In actuality it would probably be a vec<4, float> so
> that I could pass it directly on to the video card without an
> intermediate copy being made.

no problem with that. This will of course work.

> I think I can agree that vectors and matrices can store the same type
> if we allow operations to accept tuple types, if that is suitable for
> others.
> 
> Perhaps dot_product could be implemented as:
> 
> template <typename LHS, typename RHS>
> BOOST_TYPEOF_TPL( something here )
> dot_product(const LHS &lhs, const RHS &rhs)
> {
>    return lhs.get<0>() * rhs.get<0>() + lhs.get<1>() * rhs.get<1>() +
> lhs.get<2>() * rhs.get<2>();
> }
> 
> but then our vectors have to act like tuples, and then I guess you
> have to ask, why isn't a tuple adequate with a bunch of free functions
> implemented like above?  PQS would still kick in at the individual
> operation level (i.e. all of those multiplications and additions).

this is an interesting idea.

-- 
Janek Kozicki                                                         |