From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-06-17 19:23:18
Michael Fawcett said: (by the date of Thu, 15 Jun 2006 15:28:08 -0400)
> On 6/15/06, Janek Kozicki <janek_listy_at_[hidden]> wrote:
> > in current design (see parent post) it is decided that all components of
> > vector/matrix/quaternion have the same underlying type
> I was really just agreeing with the current sentiment that we should
> allow some operations and disallow others, depending on the template
> parameters. I was under the impression that the vector<3,
> free_quantity> syntax was just one alternative to the lengthier one,
> in fact, I got the impression that Leland Brown currently uses mixed
> type vectors and matrices with success. I was also unable to find the
> post where it was agreed to drop mixed types. Could you quote next
Leland Brown said:
> We can do this if we define vectors as vector<N,T> like this:
> vector<2,double> // 2D dimensionless vector
> vector<3,pqs::length::km> // 3D position vector in km
> vector<6,pqs::free_quantity> // 6-element vector of mixed units
> // (e.g., phase space)
> And I agree that this is better than:
Well, actually it is not spelt out clearly above. I have taken some
assumptions when reading above, perhaps we have here a misunderstanding,
which I really hope will be cleared now.
The point is that we can have mixed types in various categories:
A. mixing different physical quantities (like velocity, acceleration and
momentum in a single vector)
B. mixing different underlying numerical data types (like short, double
and Boost.Rational in a single vector)
My assumption is that A is allowed, and free_quantity allows to change
physical quantities during runtime, while fixed_quantity doesn't allow
Also my assumption is that B is NOT allowed, and whole vector uses the
same underlying numerical data type (ie. all fields in a vector are
Boost.Rational), and there is no way during runtime to change that
underlying numerical type.
An option (which in my understanding you favor) is to be able to declare
a vector which in each field uses different underlying numerical type.
And that those types cannot be changed during runtime. I'm curious about
opinions from other people, but personally I oppose about such
functionality. Because (as I already said): working in
physics/math/engineering makes no sense to use different underlying
types. And also because it will add extra complexity to this library,
like type promotion problems, or operator problems.
We have limited time to spend working on this library. Perhaps this
functionality could be added later, if there is really a big need for it.
What others think?
-- Janek Kozicki |