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

From: Andy Little (andy_at_[hidden])
Date: 2003-11-19 05:15:20

"Matthias Schabel" <boost_at_[hidden]> wrote in message
news:2076FF3F-1A1F-11D8-B778-000393DC6706_at_schabel-family.org...

>constructor (commented out in test_units.cpp.  Could you try
>uncommenting those
>statements in VC7.1 to see what pops out?  I don't have access to that
>compiler...
>

c:\Projects\MattSchabelDims\test_units1.cpp(171) : error C2440:
'initializing' : cannot convert from 'mcs::units::DimensionedQuantity<Y,T>'
to 'mcs::units::DimensionedQuantity<Y,T>'
        with
        [
            Y=double,
            T=mcs::units::CGSModel::velocity_unit
        ]
        and
        [
            Y=double,
            T=mcs::units::SIModel::velocity_unit
        ]
        Constructor for class 'mcs::units::DimensionedQuantity<Y,T>' is
declared 'explicit'
        with
        [
            Y=double,
            T=mcs::units::SIModel::velocity_unit
        ]

:-)    :-)   :-)  .....see later-->

( change to this and it works :

SI<double>::Velocity    v3 =
SI<double>::Velocity(CGS<double>::Velocity(7.0));
)

[snip]
> > As far as the rest goes, the MPL stuff looks very impressive
> > and I like the removal of  dimensions with power 0.
> > On that subject it would be nice once having arrived at a
> > dimensionless pq
> > to convert to the value_type direct.
> > ie ideally a dimensionless pq is never constructed
>
> Glad you like it; some parts were a bear to get right.  At the moment,
> I allow dimensionless
> quantities to be implicitly converted to/from the underlying value
> type. I like preserving
> the dimensionlessness (d15s?)

I call them dimless pqs ...whatever :-)

>so that you can distinguish between raw
> values and
> types which result from evaluation of expressions containing
> dimensioned quantities...

Yep There is an argument for that, but the problem is that you then have two
types which
represent exactly the same thing. My monolithic mind tells me that is not a
good thing.
The logical extension of your scheme which strips the Power_of_0 dimensions
is to
return one with none when its dimensionless...is all I'm saying
You either choose:
A)
some-pq<000..> =  result of division between two dimensionally equivalent
pqs
or
B)
inbuilt-type  = result of division between two dimensionally equivalent pqs

(ideally ) ...:-)

OTOH One use for a dimensionless quantity might be if it included a scale
ie degrees etc. However by definition a dimensionless temporary pq must
be without scale. So you will never construct one with a scaling factor as a
temporary.

[snip]

Because a 'dimless pq' is exactly like an inbuilt type you should be able to
use
both in exactly the same way. If you get a situation where you can only use
one or the other
trouble will soon  follow. And it is difficult to predict every
circumstance.
By definition inbuilt types are more flexible, so are the logical choice in
my view.
Otherwise you start to find it difficult to integrate pq_s into general
code.

> but I'm still working on schemes for the dimensioned quantities which
> will
> maximize flexibility.  In particular, I'm trying to concoct a good way
> to take
> two disparate models and merge them - say you have one model with
> length_tag, time_tag, and mass_tag and another with angle_tag, it would
> be nice to be able to easily create a meta-model encompassing both...

More lengthy explanation/doc  would clarify what you mean... :-)

One thing about a physical-quantity which I think is fundamental is
 that it does not try to preserve
(nor should it) all the information that is put in.

ie (representing pqs impartially ...:-)  )
length_pq<..>        a(2 units);
length_pq<..>        b(3 units);

    area_pq<..>      c  =  a * b;

There is no way to find out the value of a or b from c alone.
If there was you would end up with a 'snowball' effect where the pq gathered
more and more attributes or history
as it went through calcs. That is a recipe for diaster in a big successive
approximation loop I think
If physicists needed such a beast it would have evolved that way.

This is an extension of the argument on dimless pqs in a way.
ie a dimless pq is a scalar and it seems futile/impossible to try to predict
what it actually represents to the user.

e.g.
mass_pq a(1),b(2);
angle_pq alpha =  a / b  ;        // perverse but dimensionally correct I
flag no error

> > If you do set up a working group on units/d.a./pqs whatever I would be
> > interested.
>
> Will do.

Jan Langer proposed a/the Wiki. . I confess that I am not very clued up on
it but the name is good !
I think there already is one/ a part on physical quantities.. worth a look

>
> > What I am trying to achieve is best summed up in this previous post.
> >
> > http://lists.boost.org/MailArchives/boost/msg55344.php
> >
> > Would be interesting to see how it would look with your scheme ?
>
> I'm personally on the explicit conversion only side of the fence

Its pretty trivial to add  or remove explicit. if its that contentious put
some flag in for the user...?
I just dont see the need. Its a pain in the ***  (as exemplified nicely  by
your own problem at top of this mail :-)  )

 - the
> idea of
> setting up a system for intelligently determining the minimum required
> precision
> for the result of an arbitrary unit-containing expression sounds like
> it would be
> an interesting application for expression templates, though I suspect
> it will be
> very difficult to accomplish for general (rather than POD) value
> types...
I am going with the keep it simple approach.
I guess I am 'bottom up' you are 'top down'.
On the other hand I am working from an ideal  physical quantity model so
maybe I am top down too .

One issue is promotion
ie who is top of the promotion hierarchy when converting from/to inbuilt -
user defined types.

Its fun aint it ... :-)

regards
Andy little