[Insight-developers] Enlarging the semantics of itkVector?

Miller, James V (CRD) millerjv@crd.ge.com
Tue, 2 Jan 2001 11:28:16 -0500


I would make the itkVector a geometrical vector.  The intention was that is would a "mathematical"
vector (in the linear algebra sense) so that you could apply transformations to a vector. You should
be able to add vectors, multiply by matrices etc.  This was the reason itkVector switched to using
vnl_vector.  itkPoint should be changed to use a vnl_vector and the API should be expanded so that
the difference between two points produces a vector, etc.

If people are using the itkVector as simply a collection of data that is not meant to be transformed,
then perhaps that should be a different pixel type.



-----Original Message-----
From: Paul Hughett [mailto:hughett@mercur.uphs.upenn.edu]
Sent: Thursday, December 21, 2000 10:47 AM
To: insight-developers@public.kitware.com
Subject: [Insight-developers] Enlarging the semantics of itkVector?



Luis Ibanez and I have been thrashing out some disagreements about the
interface to the itkAffineTransform class and have--I think--come to
an agreement that the right solution requires either enlarging the
semantics of the itkVector class or adding a new flavor of Vector
class.

The key issue is that the term "vector" is overloaded and carries
distinct meanings in geometry and computer science.  In geometry, a
vector is the difference between two points and transforms in a
particular way under an affine transform; that is, you multiply by the
matrix part of the affine transform, omitting the constant part.  The
definition of vector in a vector space is slightly different but
consistent with the geometrical definition.  In computer science, on
the other hand, a vector is simply an ordered collection of scalar
values, with no implied transformation properties; in fact, it is not
even guaranteed that any transformation is possible.  (In mathematical
physics there is a further distinction between vectors and pseudovectors,
based on how they transform under parity transformations; as far as
I know, we can ignore that particular distinction.)  The itkVector
class, as currently defined, is a vector in the CS sense but not the
geometrical sense.

The AffineTransform class needs to distinguish between (geometrical)
points and vectors, since they transform differently.  The simplest
way to do this is to represent points and vectors by different
classes.

So--should we create a new class GeomVector to represent geometrical
vectors, as distinct from CS vectors?  Or should we overload the
existing itkVector class to represent both geometrical and CS vectors?

Paul Hughett

_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers