--- Geoffrey Irving <irving@cs.stanford.edu> wrote:
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)
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.
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>
PS: I like vector<3> , I think that Andy can't argue with this name :>
Or vector<T,3>
There's been a lot of discussion on this issue of vectors and how/ whether to deal with vectors or tuples of mixed units. I'd like to chime in with some of my thoughts: 1 - why I think mixed vectors are both sensible and important, and 2 - why I think this could be easy to implement, at least partially. 1. First, what's the real difference between a vector and a tuple? There are probably differences in the way they're visualized by various people, but I think we should be primarily concerned with the differences in semantics - what operations are meaningful and/or useful on each, which distinguish one kind from the other. The way I think about them, I see at least three differences: A. Vectors have operations like magnitude (length), dot products, cross products, angle between two vectors, etc. For tuples, in general, none of these functions have a meaningful definition. (This is probably why they are hard to "visualize" as vectors.) B. Vectors can be transformed to other vectors by matrix multiplication. Thus, it's useful to have them be compatible with or embedded in some sort of matrix library. Tuples typically are not suited for such use. C. Vectors, like matrices, can be indexed numerically (1st row, 2nd column, etc.), so it's easy to loop over the elements. This is part of what makes them suited for matrix calculations. Tuples are frequently referenced by name instead of number - e.g., the members of a struct. So what about "vectors" of mixed dimensions/units? As far as property, they would not act like vectors. But for property B, there *are* many engineering applications that need mixed aggregates to have these operations. The bulk of my own work falls into this category, and this is, in fact, the situation for which I developed my dimensional analysis library in the first place. Janek Kozicki also commented on the need for matrix multiplication with vectors in phase space. In my work, I tend to visualize these mentally as tuples, not as vectors in some N-dimensional space. But it turns out the mathematics I need to perform requires them to be involved in lots of matrix calculations - which also means the matrices themselves have mixed units. In summary, I think it's important to allow vectors whose elements have different physical dimensions - even though certain operations like vector length will fail unless all the dimensions are the same. 2. The good news is that I think this is almost trivial to implement using the "t3_quantity" or "free_quantity" or whatever we decide to call it. And with the other two "quantities" I found it extremely difficult to implement in a general way, so I suggest don't bother. If the user needs mixed vectors, he can use "free_quantity." (Or he can write his own matrix operations for his special case, or exit the strong typing and dimensions checking for the matrix operations.) We can do this if we define vectors as vector<N,T> like this: vector<2,double> // 2D dimensionless vector vector<3,pqs::length::km> // 3D position vector in km vector<6,pqs::free_quantity> // 6-element vector of mixed units // (e.g., phase space) And I agree that this is better than: vector<m,m,m,kg_m_div_s,kg_m_div_s,kg_m_div_s> Likewise with matrices, perhaps use matrix<M,N,T> like this: matrix<3,3,double> matrix<2,3,pws::time::s> matrix<7,6,pqs::free_quantity> etc. FWIW, in my library I made the type parameter default to double, which allows simply vector<3> if you want a unitless vector.
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.
I agree. Especially since cross products only exist for 3D, template specialization is probably needed for that case at least. -- Leland __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com