[boost] Re: Re: Re: Re: Physical quantities

From: Andy Little (andy_at_[hidden])
Date: 2004-01-14 07:14:13

"Kevin Lynch" <krlynch_at_[hidden]> wrote in message
news:40041C47.1050000_at_bu.edu...
> Andy Little wrote:

[snip]

> discussions we had on this issue back in October/November of 2001.  Many
> of the questions being discussed now have, not surprisingly, come up
before.

I have tried to read up on boost-quantities-history. One observation is that
most of the resulting libraries appear to have been abandoned.  I suspect
that the reason for that is partly the level of criticism, and 'feature
requests' :-). And possibly the shadow of SIUnits. From the current
discussion should come some flavour of the complexities/'interests'
involved... not all positive...some politics. A (physical )quantity does not
fit at all well into the 'flat' world of computing, which is based around
numeric types. Therefore those that have an 'interest' in numeric types will
not be positive. Compiler technology (and compile-speed) has evolved, new
techniques (metaprogramming) have been developed and are becoming
understood(...by me:-) ). . A 'second look' helps etc.and I have my own
'Walled garden' where I can experiment.

[snip]

> > OK... you smash atoms and then try to figure out what the bits are made
of?
>
> Yup.

The 'type' (bits of atom) is an(The) unknown? Ideally you want a  'type'
flexible enough so that you can keep trying to find one (type) that best
fits the input data?. The type *might* have physical dimensions. It would be
nice to be able to play with them? IOW  What use is a physical-quantity type
in your work? In reality you have a lot of other more important problems...
(say) raw data accuracy? In fact Most problems are raw data accuracy? A wild
guess at what you really do..  :-)

> > (Don't know what MC modelling is..probably should).
>
> Sorry ... MC = Monte Carlo.  I use it in the more general sense here,
> meaning a large simulation that uses random numbers to make certain
> choices (like whether a particle decays in this time step or not).

Monte Carlo == gambling ? From this I assume that you are not trying to use
the 'atom smasher' data direct as an input, but are creating various models
which you can then compare with your raw 'atom smasher'  data picture. (I
use 'picture' in the sense that you must make educated guess on important
features of the raw data) A wild guess at what you really do..  :-)

[snip]

> Actually, the SI system is a really nasty  :-)  Well, it is not so much
> the units (there isn't anything inherently wrong with the selection of
> units, names, and the physical unit definitions), but the understanding
> and description of the underlying mathematics of dimensional analysis
> that is inherent in the defining documents is really wacko ... it is
> almost as if the SI was political document than a scientific document
> :-)   For example, SI states that there "ARE SEVEN FUNDAMENTAL
> DIMENSIONS", which is at best an overstatement.  They should have said
> "YOU CAN LOGICALLY CHOOSE THE NUMBER OF DIMENSIONS TO SUIT YOUR NEEDS
> AND WE CHOOSE THESE SEVEN BECAUSE...."

Personally I am very grateful to those guys. I have been using SI for my
calcs for years without actually realising. To me any chance I get I now say
THANKS !
Of the 7 length,mass,time,current,temperature... and light are 'everyday'
concepts to me:
Length -->ruler
mass --> scales (implicit g calibrated)
time --> watch
current --> ammeter
temperature --> thermometer
light --> eyes

They also extend into  my 'schoolboy' physics. What is important about SI to
me is not the selection of a particular set of
dimensions, nor the units but that they can be combined in a coherent way.
(and communicated around the world)

For example:

(a force in N) / (a mass in kg) --> an acceleration in (metres per
second^2.)

What if I take units of kilograms-force:

    (a force in kilograms-force) / (a mass in kg) --> what units ?

It may be possible to extract the logic (SI is a 'retrofit' to ad-hoc units
systems) even clean it up, or define ones own.
You personally  need total control of a dimension (what it is) and its units
and some logic to combine them (a quantity)Your
view of reality is not at the same scale as the general public. Your work is
very specialised.

>
> > If we could figure out how to represent  the
> > 'logic'(s) of SI,CGS and 'natural' units, then that would (possibly)be
> > something we could allow the user to customise (usually via templates)
> >
>
> The "logic" of dimensional analysis has been quite cogently described by
>   Deane Yang.

(Understating) I find this remark slightly odd. Deane has several times
asked myself and others to explain the concepts of physical quantities. In
much of his writing he confuses quantities,dimensions and units. (Like Deane
you would like to 'make up' your own dimension/units system....this may be
what you are saying.)
If there is something in Deanes work I would like to see a more
comprehensive paper, ideally written for a 'simple guy' like myself.
(Diagrams help).
Heres mine(needs updating):

http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/Concepts.html

 I am to old to be impressed by big words and 'peer review'. Though Deane
tries to explain what dimensional analysis is in one paragraph, In the next
he says he doesnt understand it. This doesnt give me confidence. I like Math
and physics because they (ideally) place emphasis on proof. Finance places
most emphasis on self interest. Transposing physical models to 'prove'
financial ones... its too easy, no requirement for proof. (Psychologists do
the same thing)
(end diatribe)

>In the context of a proper understanding of dimensional
> analysis, a chosen system of units does nothing more than define a set
> of fundamental objects against which you can describe measurements as
> ratios.  "this board is 2m long" is the statement that "Within the
> context of SI, I am measuring this board by its length dimension, and I
> find that it is twice as large as the fundamental meter", which is a
> very well defined, but completely arbitrarily chosen, length.

One observation.. when you say 2m I know exactly what you mean. When I want
to fit a shelf , I'd rather take out a tape measure than think "What system
shall I
design that is suited to do this job and then argue with you about the best
for the next three months". If we all went  around defining our own
systems...
(same point I made above)

>
> > I assume that by non-dimensionalised calculations you mean you use a
'real'
> > type to represent a dimensioned quantity. Any dimensional analysis is
> > done(and checked) manually. Do you require a C++ framework that catches
> > errors in dimensional analysis, or is that a triviality?
>
> By "non-dimensionalized", I mean that you recast your equations directly
> in terms of dimensionless ratios instead of in terms of the division of
> two identically dimensioned quantities (usually, you then have to
> multiply by an overall dimensioned constant to maintain the proper
> units).  This is a long winded aside, but here goes:
>
> Here's an example ... in the experiment I'm working on right now, we
> have a collection of particles that decay over time, and we measure that
> decay time.  All sorts of interesting physics go into calculating the
> number of particles that will be observed to decay during a given time
> interval in a given direction.  Greatly simplified, it looks something
> like this:
>
> exp(-t/tau)*(1+cos(w*t))
>
> Where t is the time, tau is the lifetime of the particle, and w is a
> precession frequency.  Now, tau is of the order 2.2 micro s,
> w is of the
> order of a few megahertz, so t will be in the range of a few tens of
> microseconds.  Now, since you don't want to be doing all of those
> divisions at runtime,

Whoa.. my lib actually would do much better than you might think here.

    q_time::us   t(1);                    // unit 1e -6 .. stored in the
template param as  -6
    q_frequency::MHz   w(1);        //units 1 e6  ... stored in template
param as
6
    os <<  w * t;                        // add exponents at compile time  6
- -6 --> 0
 NO runtime division or multiplication at unit layer here, (fast and
accurate)
BTW with my lib the value_type is at the scale of
the unit.  hence 1 us is stored as 1.
Units are a whole new ballgame for me :-)

>and for other reasons both technical (roundoff
> errors in the real equations, etc.) and aesthetic (you think about these
> things in reference to "how many lifetimes after the collection of
> particles"), you are only ever interested in t/tau anyway.  So, you
> create a new variable T = t/tau, and recast the equation in terms of
> this.  Everything else gets recast as well: W = w*tau.  Now, you have
> the "non-dimensionalized" equation
>
> exp(-T)*(1+cos(W*T))

although the original ones (t/tau), (w*t) are dimensionless:
exp and cos would give different(unit dependent) results if used with
dimensioned quantities.

Dimensioned constants are handy:
q_capacitance::uF   const C(0.47);     //capacitor
    q_voltage::V        const V0(5);  //starting voltage across capacitor
    q_resistance::kR    const R(4.7);   // resistance between terminals

    for ( q_time::ms t(0) ; t <= q_time::ms(50); t += q_time::ms(1) ){
        q_voltage::V const  Vt = V0 * std::exp(-t /(C * R));

(-t/(C*R) ) is dimensionless.

OTOH.
time t;
 exp(t) is (Almost) Definitely an error in my unit system too.
(some 'rules of thumb' do this type of thing... but Very Explicit about
units)

>
> and you see that the new form of the equation is completely in terms of
> dimensionless quantities; it isn't obvious from this example that doing
> such a thing is a win (although even in this case, you've eliminated a
> multiply),

Although you have had to divide(somehere along the line) to get T ?
But presumably a lot of nice cancellations occur behind the scenes?
OK OK The reality Is much more complicated :-)

> but in complicated situations, it can simplify the equations
> and make the physical content more obvious (the values of T of interest
> are now centered about 1, for instance.

Basically you are avoiding creating a unit system.... but therefore can only
use dimensionless quantities.
Maybe you dont need dimensioned-quantities (which must have units)

[snip]

> > Current practise then is to fit the calculations to the limitations of
the
> > framework? Would you do it differently in an ideal world?
> >
>
> Current practice is to do just that, because the frameworks are old and
> huge (in fact, some are still written in Fortran 77, because that was
> the dominant language when their first punch cards were, well, punched).
>    The newer frameworks that are written in C++ are still old enough
> that they were started before the Standard was finalized and compilers
> began to allow portable "advanced" behavior (templates, RTTI, etc.)
> These are frameworks that, for instance, calculate real world effects in
> particle interactions with matter, and contain hundreds of thousands or
> millions of lines code, and hundreds of lookup tables of real world
> data.  The code works extremely well, is very well debugged, and well
> understood ... you don't lightly go about modifying such code to add
> unit support :-)

IOW pay your programmers well. Smile at them.. If they ever quit your
<expletive deleted>!

I accept this point (unit-support) absolutely. To me the physical-quantities
type is just for fun. It will not fit into real systems.. What I do like is
that it models what it represents in a satisfying way. When you build a
model in one situation you try to make it as close to the real thing as you
can. In another a great simplification maybe better. From what you say a
physical-quantities type is rather a triviality in your work. It would
create more problems than it solves.

>  Would I do it differently in an ideal world?  Sure
would.
>
> This is similar to the fact that most of us use C++, despite the known
> "mistakes" in the language design, or use the STL despite its drawbacks,
> or ....   They aren't perfect, but they work better than the alternatives.

I may be wrong but I think that  I could only do this (physical-quantities
type) in any expressive way in C++. I love C++. It has evolved rather than
been designed by grammar experts (Pascal). Its bottom up not top down. AFAIK
Bjarne Stroustrup originally designed it for simulations. Appears that some
of those 'bare bones' are proving very useful in my particular lib.

>
> > What would help most is the sort of thing that shows the current
problems
> > and frustrations. ie "If I could only do This...".  I dont see that it
has
> > to be related to D.A./units. Anything which is a C++ problem or could be
> > fixed by C++ would be useful.
>
> Oh, don't get me started .... give me a real array language, a generic,
> extensible interface to special functions, real floating point support,
> rational standard conversion rules, etc. etc.  We've discussed many of
> these issues on boost as well; Fernando Cacciola's Numeric Conversions
> Library; the Random, Quaternions and Special Functions libraries are
others.

I am pretty sure I shall incorporate the converter. I hope to work with
arrays
some day. FEM I think its called? Again something that works, not 'raw
performance'

>
> >
> > Oh and anything with non integer powers of dimension...preferably
> > irrational.
>
> I've never seen such a thing; and non-integer powers themselves are
> actually fairly rare.  You obviously need to be able to take rational
> powers of things, but final results are almost universally integer
> powers of units ... eg.  given the volume of a sphere, what is its
> radius?
>
>You need to take a cube root in three dimensions, but the
> result is going to be a length.  I've never seen an equation that
> requires or results in, for example, the "cube root of length".

Err .. hmm  I know that but you have to humour these guys ;-). I have
optimised on int powers then this was pulled out... nV.Hz^-.5   ...
trivia.... but
reviewing my code I may be able to squiggle in rational-powers (for their
benefit), while keeping the optimisation. :-)

> So, I don't know if any of that means anything or even answers your
> questions ... I've been flooded out of my office by a burst standpipe,
> and I've got nothing better to do than answer email from home while they
> dry it out.  So I'm in long-winded mode :-)

Thanks for the information.... and time. It has been interesting and useful.
I will try to look further into 'user definability'.Its not every day I can
say, "sorry I'm busy talking to a particle phycisist." :-)

regards
Andy Little

begin 666 Yangisms.txt
M02!S96QE8W1I;VX@;V8_at_66%N9VES;7,-"@T*(DES;B=T('1H92!W:&]L92!P
M;VEN="!O9B!D:6UE;G-I;VYA;"!A;F%L>7-I<R!T;R!D97)I=F4-"G1H92!D
M:6UE;G-I;VX_at_86YD('5N:71S(&]F(%!1;W5T7W0_at_9G)O;2!T:&4@='=O(&EN
M<'5T(&9A8W1O<G,_#0HB#0H-"@T*(@T**$YO=&4@=&AA="!M=6QT:7!L:6-A
M=&EO;B!O9B!T=V\@<75A;G1I=&EE<R!I<R!.3U0@:6X@=&AI<R!L:7-T+BD-
M"B(-"@T*#0HB#0I#;VUP;&5X('%U86YI=&ET:65S(&%R92!F;W(@;64_at_8VQE
M87)L>2!B97EO;F0@=&AE('-C;W!E(&]F#0IT:&4_at_8W5R<F5N="!U;FET(&QI
M8G)A<FEE<RX_at_2&EG:&5R(&1I;65N<VEO;F%L(&%N86QY<VES#0II<R!P<F]B
M86)L>2!U<V5F=6PL(&)U="!A(&QO="!T<FEC:VEE<B!T;R!I;7!L96UE;G0N
M#0HQ+61I;65N<VEO;F%L(&%N86QY<VES('-E<G9E<R Y,"4@;V8@=&AE(&YE
M961S+@T*(@T*#0H-"B(-"D)U="!I="=S(&=E='1I;F<@<F5A;&QY(&-O;F9U
M<VEN9R!W:&5T:&5R('1H:7,@:7,@=&AE(&1I;65N<VEO;G,-"G!A<G0@;W(@
M=&AE('5N:71S('!A<G0@*$D_at_86T@8V%P86)L92!O9B!A<F=U:6YG(&5I=&AE
M<B!S:61E*2X-"B(-"@T*#0HB#0I);B!O=&AE<B!W;W)D<RP_at_9&EM96YS:6]N
M86P_at_86YA;'ES:7,@25,@=7-E9"!T;R!F:6=U<F4@;W5T('1H92!R:6=H="!U
M;FET<RX-"@T*#0HB#0I)('1H:6YK(&5V97)Y;VYE(&%G<F5E<R!W:71H('1H
M:7,N(%1H92!Q=65S=&EO;B!I<R!W:&5T:&5R('1H90T*='EP97,@(G5N:70Q
M(BP@(G5N:70R(BP_at_86YD(")U;FET(B!S:&]U;&0_at_8F4@<F5P;&%C960_at_8GD-
M"B)D:6UE;G-I;VXQ(BP@(F1I;65N<VEO;C(B+"!A;F0@(F1I;65N<VEO;B(N
M#0H-"BA">2!N;W<L($D@=&AI;FL@=&AE>2!S:&]U;&0_at_8F4@9&EM96YS:6]N
M<R!W:71H(')E<W!E8W0@=&\@97AP;&EC:71L>0T*<W1A=&5D('5N:71S+"!W
M:&EC:"!I<RP@:6X_at_9F%C="P@=VAA="!)('1H:6YK('-O;64@;V8@=&AE('!R
M;W!O<V%L<PT*86-T=6%L;'D_at_9&\N(%EO=2!W86YT('1O(&%L;&]W('1H92!S
M86UE(&1I;65N<VEO;B!B=70@=VET:"!D:69F97)E;G0@#0IU;FET<RP_at_04Y$
M('EO=2!W86YT('1O(&%L;&]W(&1I9F9E<F5N="!D:6UE;G-I;VYS('1H870@
M=7-E('1H92!S86UE#0IU;FET<RX_at_02!G:79E;B!T>7!E('-H;W5L9"!S<&5C
M:69Y($)/5$@@=&AE(&1I;65N<VEO;B!A;F0@=&AE('5N:70N*0T*(@T*#0H-
M"B(-"CX_at_5VAA="!I<R!T:&4@<F5S=6QT(&]F#0H^("!T;W)Q=64H,2XP*2 O
M('=O<FLH,2XP*0T*/B _("!)(&%S<W5M92!I="!H87,@9&EM96YS:6]N86QI
M='D@(G1O<G%U95XQ+'=O<FM>+3$B+B @3W(@9&]E<R!I="!H879E(&YO#0H^
M(&1I;65N<VEO;F%L:71Y/PT*#0I);B!T:&4_at_9&EM96YS:6]N<R!L:6)R87)Y
M($D@=V%N="P@=&AE('5S97(@=V]U;&0_at_8F4@86)L92!T;R!D96-I9&4@=VAI
M8V_at_-"F)E:&%V:6]R('=O=6QD(&]C8W5R+@T*(@T*#0H-"B(-"DEF($D_at_86T@
M=W)I=&EN9R!A(&-O9&4@;6]D=6QE('1H870@=7-E<R!O;FQY('1O<G%U92!A
M;F0@;F]T('=O<FLL#0IT:&5N($D@=V]U;&0_at_9&\@=&AE(&9O;&QO=VEN9SH-
M"F$I(&EN<VED92!T:&4@:6UP;&5M96YT871I;VXL(&1E9FEN92!O;FQY('1H
M92!D:6UE;G-I;VYS(&9O<F-E(&%N9" -"FQE;F=T:"!A;F0_at_86QL;W<@=&]R
M<75E('1O(&)E(&UE87-U<F5D('5S:6YG('1H92!D:6UE;G-I;VX_at_9F]R8V4@
M*B!L96YG=&@N#0HB#0H-"@T*(@T**$)Y('1H92!W87DL(&UY(&]T:&5R(')E
M86-T:6]N('1O('1H92!A;6)I9W5I='D@;V8@(F9O<F-E("H@;&5N9W1H(@T*
M:7,@=&AA="!T:&4@=7-E9G5L;F5S<R!O9B!O=F5R;&]A9&5D(&]P97)A=&]R
M<R!I<R!P<F]B86)L>2!O=F5R<F%T960N#0I%86-H(&]P97)A=&]R*B!P<F]B
M86)L>2!S:&]U;&0_at_8F4@<F5P;&%C960_at_8GD@82!F=6YC=&EO;B!W:71H(&$@
M;6]R90T*:6YF;W)M871I=F4@;F%M92X_at_1F]R(&5X86UP;&4L(&EN('1H92!W
M;W)L9"!O9B!F:6YA;F-E+"!T:&5R92!A<F4-"G1W;R!D:69F97)E;G0@='EP
M97,@;V8@;75L=&EP;&EC871I;VXL(&UU;'1I<&QI8V%T:6]N(&)Y(&$@9&ES
M8V]U;G0@#0IF86-T;W(@86YD(&UU;'1I<&QI8V%T:6]N(&)Y(&$@<')O8F%B
M:6QI>2X_at_22!F:6YD(&ET('%U:71E('5S969U;"!T;PT*9&ES=&EN9W5I<V@@
M8F5T=V5E;B!T:&4@='=O(&)Y('5S:6YG('1W;R!D:69F97)E;G0_at_9G5N8W1I
M;VYS+"!E=F5N#0IT:&]U9V@@.3DE(&]F('1H92!T:6UE('1H92!T=V\@9G5N
M8W1I;VYS(&1O(&5X86-T;'D@=&AE('-A;64@=&AI;F<N#0I/=&AE<G=I<V4L
M('1H92!R96UA:6YI;F<@,24@:7,@82!R96%L(&MI;&QE<BX_at_270@:&%S('1H
M92!A9&1E9"!B96YE9FET#0IO9B!M86MI;F<@=&AE(&-O9&4_at_96%S:65R('1O
M('5N9&5R<W1A;F0N*0T*(@T*#0H-"B(-"DYO+"!U;F9O<G1U;F%T96QY(&YO
M="X_at_0F5C875S92!)(')E86QL>2!D;R!N965D('1O(&1O('1H92 -"FUU;'1I
M<&QI8V%T:6]N<R!A;F0_at_9&EV:7-I;VYS(&%N9"P_at_87,@>6]U(&]B<V5R=F5D
M+"!T:&ES(&ES('1H92!K97D-"F9E871U<F4@;V8@=&AE(&1I;65N<VEO;G,@
M;&EB<F%R>2X-"B(-"@T*#0HB0GD@=&AE('=A>2P@=VAA="!E>&%C=&QY(&1O
M('EO=2!U<V4@>6]U<B!D:6UE;G-I;VYS(&QI8G)A<GD_at_9F]R/R(-"@T*(@T*
M/B!*=7-T('1H92!F86-T('1H870_at_9&EM96YS:6]N86P_at_86YA;'ES:7,@:7,@
M<V\@87!P;&EC86)L92!T;R!S;R!M86YY( T*/B!A<F5A<R!P<F5S96YT<R!A
M(&=O;&1E;B!O<'!O<G1U;FET>2!T;R!C;VUE('5P('=I=&@@<V]M971H:6YG
M(&UO<F4@#0H^(&=E;F5R86P_at_86YD('5S969U;"!T;R!A;&P@;V8@=7,N#0H^
M( T*#0I997,A#0HB#0H-"B(-"D%L<V\L($D@<F5A;&QY+"!R96%L;'D_at_9&\@
M;F]T('=A;G0_at_82!L:6)R87)Y('1H870_at_86QL;W=S(&-O;G9E<G-I;VX@;V8@
M#0IT;R!M:6YU=&5S+"!S96-O;F1S+"!O<B!M:6QL:7-E8V]N9',@;W(@<W1O
M<F5S('1I;64@:6YT97)N86QL>2!I;B!T:&5S92 -"G5N:71S+B!)="!W;W5L
M9"!D969I;FET96QY(&%D9"!T;R!M>2!D96)U9V=I;F<@:&5A9&%C:&5S#0HB
&#0H-"@T*
`
end