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