[boost] Re: new compile-time dimensional analysis and unit library

From: Andy Little (andy_at_[hidden])
Date: 2003-11-19 22:14:27

"Matthias Schabel" <boost_at_[hidden]> wrote in message
news:A0372BA0-1AC9-11D8-B778-000393DC6706_at_schabel-family.org...
> > ( change to this and it works :
> >
> > SI<double>::Velocity    v3 =
> > SI<double>::Velocity(CGS<double>::Velocity(7.0));
> > )
>
> Right - I forgot that the assignment form is not the same as
> the normal constructor...

Sorry reading back my last post it reads harsher than intended.
However the alarm bells should ring,
If it catches you out now it will alienate me as the user too....
Inexplicable errors on perfectly reasonable concepts.
As I said later in last post . Its pretty trivial to add explicit.
In the above context this is a policy.
BTW I use explicit on initialisation by value.,
but I would argue that is structurally necessary to prevent pq falling
apart. If not:
pq_velocity<>::m_per_s v1(1),v2(2);
pq_force<>::N                f  =  v1 /  v2;                    // no error
If its contentious I would be strongly in favour
of a switch for make unit conversion explicit yes or no.
Of course it would have to extend from no, else it would break my code.
Start off less restrictive and then impose the policy.

[snip]

> Hmmm...I would argue that the dimensionless result of a unit
> computation is
> fundamentally different than a normal POD value - for example, units of
> angular
> measure are technically dimensionless, but there is clear value in
> keeping track of
> them.

I should have said "the underlying value_type" , not inbuilt type.
You are raising the bar quite high in being able to predict how the lib will
be used.
You need to be careful to avoid frustrating the user, with error messages on
perfectly reasonable
calcs.
I would say that once they have entered the pq system they conform only to
the D.A rules.
They are entities with  powers-of-dimension and units.
( Units on dimensions of power 0 (if implemented :-)  ) are 'dont care' )
The programmer imposes a type on the entity when it is ouput.
A physical quantity consists in a concise amount of information. Keep it
simple.
e.g
pq_length<float>::m length1(1), length2(1);
pq_angle<float>::radians alpha  = length1/length2;
pq_angle<float>::degrees beta  = length1/length2;
// note the angles are Not physical quantities, but are compatible.
pq_length<float>::m  length1a  = alpha * length2;
pq_length<float>::m  length1a  = beta * length2;
presumably you do not want  length1a/1b to be a
pq_length_was_radians_by_a_length<float>::m length1a; //.........?
pq_length_was_degrees_by_a_length<float>::m length1a; //.........?

> > The logical extension of your scheme which strips the Power_of_0
> > dimensions
> > is to return one with none when its dimensionless
[snip]
>
> If you're representing your dimensions as a fixed length list, this
> works fine, since you
> can catch dimension<0,0,0,0,0,0,0>.  However, you run into a problem
> when implementing
> it as I have as a variable length list of tagged dimensions:
>
> mpl::list<dim<t1,0>,dim<t2,0>,dim<t3,0> >
>
> and
>
> mpl::list<dim<t4,0>,dim<t5,0> >
>
> are both dimensionless, but would not be recognized as equivalent if I
> didn't reduce them to a
> specific dimensionless_type...

Thats an implementation problem.... I did say Ideally :-)
However I conjecture that you can catch all instances where a dimensionless
type will be created.
ie in division of two types of equivalent dimensions and multiplication of
one with *times -1* equiv dims of other
power of 0 etc. I think that covers it but may be wrong.
So whatever the implementation I dont think it would be too difficult to do.

[snip]

>  You need to bear in mind that the dimension code can exist on
> top of arbitrary value
> types, though - it's not just restricted to PODs :
>
> typedef
> DimensionedQuantity<boost::array<double,5>,SIModel::length_type>
> dvec_type;

Yes I see your point.. well sort of. My immediate thought on implementing
arrays/vectors would
be just as a a vector of pqs... presumably the above has advantages over
that scheme ?
BTW  boost::array<double,5>   does that work ?
Incidentally one( real or imagined) problem with use of a lot of MPL is
compile time.
its a dirty word but has to be taken into account in a practical system.
if it takes too long to compile,as a user I wont use it -  end of story.

> If anything, I think your example is a point in favor of disallowing
> implicit conversions
> from dimensionless types - at least then it would be clear that the
> programmer
> intended to do something strange...

On the one hand you argue for flexibility, but only on your terms. ( Who
decides what is 'strange'?
The angle = mass/mass example makes sense if mass is some function of
length)
This is one major criticism of your lib overall, that it imposes policies.
The most obvious example is in the use of unit policies as namespaces.
Overall I hope you would agree that some documentation would help
to convey the ideas behind your library. (I am working on that for mine but
takes time !)
There are some things I like such as the mpl lists (vectors is an
alternative) but from what you are saying your implementation
is already locking you in. It is a fact of design in my experience
 that you have to be prepared to throw away the implementation, however
excellent, if it does not conform to the
concept/specification or if the concept it models is flawed.
I suspect that our ideas are pretty different underneath on which way this
should go, but that is a good thing.
Some things are already emerging as major important issues, e.g unit
conversions and the dimensionless issue.
My current view is that we should keep the two ideas separate initially, do
more work and see how each works in practise.
If the overall scheme is useful then see a single solution as a long term
aim.
Some things could be agreed ie names if there is a common entity.
e.g I think we have the same name/syntax for power/root.
Bjarne Stroustrup stated somewhere that (I think) a good idea will have many
reasonable solutions.

regards
Andy Little