[boost] Re: Re: pqs-1-00-00 is up at yahoo

From: Andy Little (andy_at_[hidden])
Date: 2003-12-11 09:51:38

"Dan W." <danw_at_[hidden]> wrote in message
news:6.0.0.22.0.20031210075840.027e2460_at_pcp.softhome.net...

> 'there IS interest;  no news == GOOD news... ;-)  Great write-up.

Thanks. I've spent a long time defending so its nice to get some
encouragement for a change :-)

> I'm
> nobody to make suggestions here, but I just thought that you and Matthias
> Schabel could team-up:  He appears to be ahead in code, but behind in
> docs;  you appear to be behind in code but ahead in docs ... ;-)

Hmm .. if your suggesting I document his code for him... no thanks ;-)
(On my side pqs-1-00-01 is a major improvement.. pqs-1-00-00 contained some
big
red-herrings(odd fish ...things that appear important but are irrelevant)
    I have downloaded and looked at Yanl and Yanl2. and made some comments
on
the original to Matthias some time back.
Therefore I hope he doesnt mind me reiterating it here.
    The MPL lists are impressive to a non MPL guru.... but.... The effect on
compile time is not. I am all for MPL etc but
limiting it to where it is absolutely necessary... seems prudent to me.
However that is an implementation thing...The major problem to me is the
syntax:
(Yanl2 "test_units.cpp",line 194)
SI<double>::Temperature    T = (273.+37.)*_kelvin;
SI<double>::Pressure       P = 1.01325e5*_pascals;
SI<double>::Length         r = 0.5e-6*_meters;
etc.
    I think SIUnits originally started this approach, with Walter Brown,
http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/SIunits/doc/0SIunits.html
with same style
quoting from ref above:
"
  Mass    effectiveMass( 1.05 * m_e    ); // m_e is electronrestmass
  Speed   fast( 10000 * meter / second ); // not so fast compared to c!
"
hence some of the criticism I have been getting is I guess on his behalf.
I dont really want to get involved in challenging any C++ gurus so.
What else  can I say ...sorry  SIUnits is not for me...
( Nevertheless I think SIUnits was the first Major attempt to sort out the
problems.
and C++ was different then, so I have no doubt directly or indirectly
benefited from this.)

 So units are always required... make them part of the type:
pq_velocity<double>::m_div_s  v1(2);
now with a shorter version , wrapping a double value_type:
q_velocity::m_div_s      v1(2);
q_mass::e                   effectiveMass(1.05);
q_velocity::m_div_s     fast(10000);
No calcs involved in the ctor and the code documents itself.
    Further differences with Yanl
Dimensionless quantities are inbuilt types. If you make a separate
dimensionless type with
an operator value_type,( my original code did this) something somewhere will
trap. I cant remember specific situations,
but I think there are some where no conversions are considered. template
ctors???
Best way to avoid the problem is just never to construct a dimensionless
type... its unneccessary
Further.. angles...
Again tried various things. My conclusion is they should be a separate
type. They are useful on their own
so shouldnt be dependent on pqs..
    (The S.I.  policy of incorporatiing of radians into its base units is I
think
a red herring. However pqs-1-00-01 acknowledges the great debt to the  SI
system. in uniting
all the physical quantity types into one coherent system.
I had tried to avoid a particular units policy, but the S.I. system has so
many advantages
 that I have ended up accepting it as the basis of  my implementation in
this version. )
    OTOH there may be a need for an additional tag param/type whatever to
distinguish
the "colloquial names of units" e.g lumen . == cd , N.m == J
Perhaps this is a question of some type that you cast to to hang your
required unit name for output. I think.
It would get lost or distorted if involved in the general confusion of calcs
within the system
>
> One thing I worry about on the code side is template name lengths. This
> goes for just about anything boosty. Not just a matter of some compilers
> being limited to 512 character identifiers, but also from the point of
view
> of understanding messages in the debugger.

Yep calling the namespace 'physical_quantities' wasnt too bright ...maybe
just
'physics' or   'pqs'.

> Someone wrote a column for CUJ a number of issues ago, about a technique
to
> trim template names by deriving a class from a long template name class.

David Abrahams .. ?   :-)

> Or is it already used, and I'm just late for the party?  ;-)

Yep I have tried it... and am using it in some places(Thanks David
Abrahams).
I am still trying to figure out where it is useful and where its not..may
depend on compiler
Overall main aim is about getting something that works currently...but will
experiment more.

>
> Back to quantities and units, I'm also curios how will they play together
> with the constants project.

ok but math constants != physics constants

>
> And I'm also curious how will it integrate with numerics. One error often
> made in numerical programming is the use of floating point types as
> accumulators or integrators, unaware of the fact that precision decreases
> with the magnitude of the value stored.

Supreme accuracy is not as often required as mathematicians like to believe
:-) Physical_quantities model analog 'stuff'. Measurement is  always
inaccurate,
The real world  of physics is nice and dirty unlike the clean pure world
mathematicians live in. In some real systems the crunching get so impossibly
complex...its chucked
out.. fuzzy logic is used... a mathematicians nightmare :-) :-)

>For angles, a neat solution for an
> 'angle-accumulator' variable is to use a fixed point 32-bit unsigned
> fractional, whose overflow value matches 360 degrees, yielding a
> non-degrading resolution of 3.314 milli-arc-seconds.  A 64-bit unsigned
> fractional can be used for more precise astronomical integrations.  The
> advantage of mapping the numeric representation's natural overflow to 360
> degrees is that it implements a 'circular number' without the added cost
of
> boundary checks or mod operations... less code, better performance.

Yep ...on angles should they wrap or just get bigger:
e.g  q_angle::revolutions revs = 100;
 Perhaps there should be two types :
q_angle::rad alpha;;
q_accumulated_angle::rad omega; :-)

I will say though that the physical-quantities types is primarily about ease
of use not performance.
Its designed from a programmer-users point of view.. I hope.

> Just throwing that in, as an example of how platform configuration ties
> with numerics, which again tie with units and with constants.  It would be
> nice to see all these separate projects eventually merge and offer a
> comprehensive solution addressing the whole field of value semantics.

Ok but Physics rules .... ouch ! :-)

> Just my $0.015.

Thanks for the encouragement. I have nearly been knocked down by it all ,
but am still standing .. just. :-)

regards
Andy Little