Boost logo

Boost :

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

"Dan W." <danw_at_[hidden]> wrote in message

> '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
red-herrings(odd fish ...things that appear important but are irrelevant)
    I have downloaded and looked at Yanl and Yanl2. and made some comments
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
(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;
    I think SIUnits originally started this approach, with Walter Brown,
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
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
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
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
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
> of understanding messages in the debugger.

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

> Someone wrote a column for CUJ a number of issues ago, about a technique
> 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
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
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
> 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. :-)

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at