Michael Fawcett said: (by the date of Thu, 15 Jun 2006 15:28:08 -0400)
On 6/15/06, Janek Kozicki <janek_listy@wp.pl> 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 |