RE: [boost] Eric Ford's Unit package

From: Eric Ford (azsro001_at_[hidden])
Date: 2003-03-05 19:34:23

> This looks most interesting, and there most definitely remains a 
> great need for 
> a units handling package. 
>
> I presume you have looked at W W Brown's SI units proposal 
> http://home.fnal.gov/~wb/SItempl8.pdf 
> and wonder why you rejected it and how your proposal is different. 

Yes, I had seen his old code, but not this proposal.  (I have not seen
a version of his code which implements his proposal.  Please let me
know if you can point to one.)  I share many of his goals, and
certainly benefitted from reviewing his code.  I'll outline some of
the differences below.

Motivation:

- From his proposal:
    - Application of current software technology to numeric physical concepts
    - Convenient (near-trivial) expression in such applications
    - General utility rooted in existing standards
    - Use of nomenclature from our problem domain
    - No attendant run-time performance penalties

- His library does not allow for additional, non-SI units (e.g. money, memory).

- His library does not allow for strongly typed distinctions between
quantities of the same dimension (e.g., kilograms of apples versus
kilograms of oranges).

- While his proposal allows for fractional dimensions, the version of
his code that I have does not.

- While his proposal mentions standard compliance and Kai, the
version of SIUnits which I have appears to have been developed
primarily with MS C++ in mind.  I was unable to get SIunits to compile
with g++.  My library compiles with g++, and I've tried to make it all
valid C++ (please notify me if you find shortcomings).  I have not
attempted to make it work with non-compliant compilers (e.g., those
which do not support for partial template specialization).  If others
would like to help make it support other compilers, I would appreciate
it.

Similarities/Differences:

- My fraction_ct class closely resembles his Ratio class.  Mine uses
the boost/math/common_factor_ct class, while his uses his own Gcd class.

- My dimlist (short for dimension_list) class closely resembles his
List class.  A difference is that I perform dimensional arithmetic
using separate classes for each operation (multiply, divide, raise 
to power, etc.) rather than his ListCombine class which takes an
extra operator tag parameter.  I believe this is a little easier
for compilers and see no significant downside.

- I tag each dimensioned quantity as belong to a system of dimensions, 
while he uses the term view.  

- My base_dimen class is similar to his Anon class.

- His proposal claims to allow arithmetical expressions involving
physical quantities expressed in different systems.  (But the version
of his code which I have does not.)  The draft version of my code
posted does not allow for such automatic conversions.  (Although a
power-user could implement such automatic conversions within my
framework.)  I choose my convention of strongly typed dimensional
systems on purpose, but am willing to hear debate on the subject.

- SIUnits includes many many units (e.g., figerlength), while mine at
present includes a smaller number of less commonly used units.  My
rationale in choosing which to include was:
  + If it is an official SI unit, include it.
  + If it seems very common to me, include it.
  + If it would be somewhat difficult for a user to construct, include it.
  + Otherwise, let the user declare it themselves.  Hence, units like
meter_per_second were left out, since a user could easily say "length
fingerlength = 4.5 * inch;".  Again, I'm open to debate on this issue.

- SIUnits includes several more dimensions predefined (e.g.,
AreaDensity, AreaPressure, BioMassDensity, and SurfaceDensity which
all have dimensions of mass * length^-2.  I'm very agreeable to adding
more dimensions to mine (since it's slightly more "difficult" for
users to add their own dimensions than to add their own units), but
would prefer not to go as far as SIUnits has.  Perhaps the most
noticeable omission from mine at present is the various forms of
density.  Since the word density is used so many ways (e.g., different
dimensionalities, whether number density or mass density), I think it
might be better to only include it when accompanied by other terms
that make it's mean clear (e.g, magnetic_flux_density).

- SIUnits includes some "advanced" features which introduce run-time
cost, while my library does not include such features.  The main
example is the ability within SIUnits to change at runtime that a
dimensioned quantity should be displayed in terms of various units
(introducing an automatically applied scale factor) and with various
labels (used when printing).  While I "power user" could implement
this within my framework (e.g., by specializing scale and label in
mks_tag), I don't see much point.  If I want a time in years rather
than seconds (default in mks), I can easily write cout <<
time_till_graduation / year;  

Main additional features of my library 

- My library provides two base dimensions in addition to the 7 SI base
dimensions.  While a "power user" could use whatever 9 dimensions they
want, I figure that the most common use of these extra base dimensions
will by money (kilograms per dollar).  Yes, I know that technically
the money thing can be viewed as a pure counting number, but I don't
believe that the non-scientific community thinks that way.  Besides,
we can money is a pure counting number.  But then quantites such as
kilograms per dollar would have the same dimensions as kilograms.  The
users would be basically lose the type-checking when performing
operations involving amounts of memory and money.  Users could confuse
kilograms with kilograms per dollar.  Since ones of the purposes of
such a library is to prevent this kind of error, I believe providing
an extra couple of dimensions is a feature.

- My library allows for users to add qualifiers to dimensioned
quantities which are strongly typed by default.  Users may choose weak
typing (e.g., automatic conversion from mass of apples to mass of
fruit or allowing a sum of mass of apples and mass of oranges to equal a
mass of fruit) by relatively easy specializations.

Thanks,
Eford