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