Re: [boost] [Review][PQS] Review deadline

From: Geoffrey Irving (irving_at_[hidden])
Date: 2006-06-13 16:21:23

On Tue, Jun 13, 2006 at 09:13:43PM +0200, Janek Kozicki wrote:
> Geoffrey Irving said:     (by the date of Tue, 13 Jun 2006 09:30:39 -0700)
> 
> > I would suggest that instead of trying to make an extremely general vector
> > class, it'd be better to make an extremely specific vector class, together
> > with an extremely general way to other vector classes.
> > 
> > Specifically, you can make vector3 (or vector<3>, perhaps) a
> > straightforward single unit Euclidean vector.  It can have L2 norms and
> > L^inf norms and cross products and all the operations that are undefined
> > for vectors with components of different units.  Then we could define a
> > vector space variant of boost::operators to convert any tuple-like type
> > into a vector space type.
> 
> I like this idea very much. Not general, but specific, with underlyings
> exportable to other classes.
> 
> >  If you wanted phase space, you'd do something
> > like this:
> > 
> > template<class Q,class P>
> > class phase_vector:public boost::vector_operators<phase_vector>;
> <snip>
> 
> I'm afraid that this example is too simplified. phase_vector would need
> the ability to be multiplied by matrix_with_units (weird name I know ;)
> - but it's rather not a phase_matrix)

This example handles that just fine, except for one detail.  You just define
a matrix_operators class, and then define multiplication between any class
inheriting from matrix_operators and anything inherited from
vector_operators where the types match.  The annoying detail is that you'd
have to return the right type, so you'd need some policy method for
specifying return types of such things.

For my personal use, I wouldn't mind having to specify a bunch of policy
details each time I defined one of these special vectors, since all the
policy details would hopefully have intuitive physical meanings.  Assuming
it's possible to set them up in a way that captures all the reasonable
operations, that is.

> > and the vector_operators class would fill in scalar multiplication and
> > addition-related operators.  In my opinion, this would be far more
> > useful than writing phase space as
> > 
> > vector<m,m,m,kg_m_div_s,kg_m_div_s,kg_m_div_s>
> 
> indeed it would be more useful, once get right. But I have the
> impression that it will be more difficult than getting vector<3> right,
> or getting units system right :/

> 
> PS: I like vector<3> , I think that Andy can't argue with this name :>

Or vector<T,3> since there's no reason not to allow floats and ints.
Templatize specialization is probably required to get all the lower
dimensional versions fast, but that's happily transparent to the user.
Specialization also allows the low dimension versions to have nice member
variables like x,y,z.

> In fact all this discuccion is great for deciding about a specification
> of such a library. When specification is agreed upon, then implementation
> should be easy enough :)

Geoffrey