Re: [boost] Any interest in dimensional analysis for orientational dimensions and Euclidean vectors?

From: Andreas Harnack (ah.boost.04_at_[hidden])
Date: 2007-03-09 06:07:41

me22 schrieb:
> Are there any situations where points can't be adequately handled as
> vectors from the origin?

Probably not; I'm not a mathematician, but I think you can even 
prove that there are non.

Tom is right in pointing out, that points are not vectors; the 
question is, is this relevant for a vector (or physical 
dimension) library. I'm getting more and more convinced that it 
isn't for the implementation, but for its scope. Discussing this 
issues might help to draw the line between things that should go 
into the library and the thinks that shouldn't.

Points can't be handled directly since they are real world 
objects. We can, however, define a vector space by picking an 
origin (and a set of base vectors) and represent the resulting 
positional vectors by tuples of numbers.

Crucial here is, that the vector space doesn't exist per se, but 
is the result of our choice. Different choices will lead to 
different vector spaces and to more or less complicated 
representations of the things we want to describe. Typically 
we'll pick an origin, that makes calculations as simple as possible.

Points are not vectors. You can't, for instance, add points and 
you can't multiply them with a scalar, that works only with 
their positional vectors. It would be nice to have a 
representation of points that is independent of any choice we 
make, but this is impossible. Since any coordinate system needs 
an origin, there's indeed no need to abandon the 'richer' 
concept of vectors in favour of simple coordinates other then 
the wish to make this distinction explicit.

Members of different vector spaces can't generally be combined, 
vector operations are defined only for members of the same 
vector space. That might explain the problems arising when 
dealing with different units for the same physical dimension, 
like temperature. Kelvin, Celsius and Fahrenheit define 
different vector spaces with different origins, which might 
(like Kelvin and Celsius) or might not (like Fahrenheit) use the 
same base vectors. Transforming one into another is a vector 
space transformation and a chapter of it's own.

Tuples form a vector space that's capable of representing all 
vector spaces that can be created by picking an origin in any 
space of geometrical points. The job of the library is to 
provide a representation for that tuple vector space. That 
includes neither the selection of a suitable vector space in the 
application domain nor the transformation between different 
possible choices. Both is part of the application design process.

Each instance forms a single tuple vector space. The user is 
free to use several instances in an application, but its the 
users job to keep them apart and define relations between them.

An excellent example how this might work is (physical) 
dimensional analysis. All values of a single unit (!) form a 
vector space, that can be represented by an instance of a tuple 
vector space. Dimensional analysis actually performs vector 
space transformation by mapping, for example, a member of a 
vector space distance and a member of a vector space time to a 
member of a vector space velocity. Dimensional analysis, 
however, does not necessarily (and probably should not) make a 
particular choice for vector spaces in the dimensional domains. 
That again is application specific an should be left to the user.

Best regards,
Andreas