Boost logo

Boost :

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
> time?

Hello Michael,

Quote:
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:
>
> vector<m,m,m,kg_m_div_s,kg_m_div_s,kg_m_div_s>

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
that.

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                                                         |

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk