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 |