Interesting! But I'm surprised there is no mention of how a strong type system can be used to enforce these semantics while programming. ;-)

OK OK. I figure it was only to keep the post on a single topic. I've always found it entertaining to find ways to represent the two with types with relations that support the different semantics but with implementations that maximize code reuse between the two. The one sticking part, for me, is what to call the entity that defines the common aspects of the implementations. I've used "basis" in the "the underlying support or foundation for an idea, argument, or process" sense before. However, "basis" means something more specific in linear algebra so I don't really like it. Any ideas?

For instance:
In O'Caml, I played with an implementation like this:

type basisType = [`Point | `Vector];;

type 'a basis =
{ x : float; y : float; z : float; }
constraint 'a = [< basisType ];;

type point = [`Point] basis;;
type vector = [`Vector] basis;;


Notice vector and point were defined as parameterizations of a type. In this case I used "basis" as the types name.

In C++ I did something similar and used basis in the types name also.

Maybe "value array"?

(Reply) (Thread)

I thought you'd be interested in this one. You know me, strong typing is definitely underlying this post.

As for what word to use, I think base is the right word. That's what the g++ STL implementation uses. In bits/stl_vector.h you'll see this:

class vector : protected _Vector_base<_Tp, _Alloc>

I'm not literate in O'Caml, but I know what you mean. In this case I think we can just be mathematically pedantic to figure out how to do it: if an affine space is a vector space without an origin, then a vector is an affine point with some additional properties. Then we could just do

struct affine_point3 {
  double data[3];
  // ...
};

struct vector3 : public affine_point {};

double operator*(const vector3& a,
                 const vector3& b) {
  return std::inner_product(a.data, a.data + 3,
                            b.data,
                            0.0);
}

// etc.

Of course, to be fully generic we don't want to limit ourselves to three-dimensional space; we should be prepared to deal with abstract points such as functions or sequences.

(Reply) (Parent) (Thread)

Cool. The word 'affine' is very familiar to me from a graphics point of view, because the affine transformations are the ones you generally want to apply to objects (the linear transformations being inadequate because they do not allow translation). I don't immediately see why the affine transformations would be a superset of the linear transformations, though; from the above it seems like they ought to be a subset. I haven't thought about it much, though.

(Reply) (Thread)

Affine transformations are a superset of linear transformations because all linear transformations are affine transformations. In particular, they are the affine transformations with a center of rotation of the origin.

The rest of the affine transformations are nonlinear (in n dimensions). As I understand it, homogeneous coordinates are used in graphics because in n+1 dimensions, affine transformations are linear (allowing the magic of the OpenGL matrix stacks to work).

(Reply) (Parent) (Thread)

I work with AffineTransforms a fair bit. Mostly with the graph (that's nodes-and-edges type graphs, not charts) package we use. They're involved in many bits, mostly transforming between graph-space and screen-space and another space that's a little annoyingly complicated. :) I have to make some tweaks to the EdgeRenderer soon, so I'll be messing with them again....

(Reply) (Thread)