On Tue, Jun 13, 2006 at 09:13:43PM +0200, Janek Kozicki wrote:
Geoffrey Irving said: (by the date of Tue, 13 Jun 2006 09:30:39 -0700)
I would suggest that instead of trying to make an extremely general vector class, it'd be better to make an extremely specific vector class, together with an extremely general way to other vector classes.
Specifically, you can make vector3 (or vector<3>, perhaps) a straightforward single unit Euclidean vector. It can have L2 norms and L^inf norms and cross products and all the operations that are undefined for vectors with components of different units. Then we could define a vector space variant of boost::operators to convert any tuple-like type into a vector space type.
I like this idea very much. Not general, but specific, with underlyings exportable to other classes.
If you wanted phase space, you'd do something like this:
template<class Q,class P> class phase_vector:public boost::vector_operators<phase_vector>; <snip>
I'm afraid that this example is too simplified. phase_vector would need the ability to be multiplied by matrix_with_units (weird name I know ;) - but it's rather not a phase_matrix)
This example handles that just fine, except for one detail. You just define a matrix_operators class, and then define multiplication between any class inheriting from matrix_operators and anything inherited from vector_operators where the types match. The annoying detail is that you'd have to return the right type, so you'd need some policy method for specifying return types of such things. For my personal use, I wouldn't mind having to specify a bunch of policy details each time I defined one of these special vectors, since all the policy details would hopefully have intuitive physical meanings. Assuming it's possible to set them up in a way that captures all the reasonable operations, that is.
and the vector_operators class would fill in scalar multiplication and addition-related operators. In my opinion, this would be far more useful than writing phase space as
vector<m,m,m,kg_m_div_s,kg_m_div_s,kg_m_div_s>
indeed it would be more useful, once get right. But I have the impression that it will be more difficult than getting vector<3> right, or getting units system right :/
PS: I like vector<3> , I think that Andy can't argue with this name :>
Or vector<T,3> since there's no reason not to allow floats and ints. Templatize specialization is probably required to get all the lower dimensional versions fast, but that's happily transparent to the user. Specialization also allows the low dimension versions to have nice member variables like x,y,z.
In fact all this discuccion is great for deciding about a specification of such a library. When specification is agreed upon, then implementation should be easy enough :)
Geoffrey