[boost] Re: physical units library

From: Jeffrey C. Jacobs (darklord_at_[hidden])
Date: 2002-10-17 12:51:52

Interesting

Well, IMHO I am bias as I too was working on something like this but am not
production-ready so if Vladimir is happy with it I suppose I can support it
if only for the like-minded sentiment that SOME units library would be
useful.

That having been said, in general I would prefer something a little more
like the FermiLab approach as it seems more intuitive to me.  Namely, it is
nice to simply be able to write:

5 * cm;

Which is what is happening intuitively IMHO.  I think the idea of
pre-defining cm and ALSO not polluting the global namespace with it
(si::abbreviation::cm) unless the client wants to is a nice touch.  I do
agree that compile-time structs are probably best and done via MPL strikes
me as the right way to go.  However, I am also a bit squeamish at any sign
of code bloat.  Happily you are only defining typedefs and empty structs
which should not generate any compiled code so this I like!

FermiLab's approach does seem to lack an MPL touch so I will say in this
sense I like what you have done.

I am though a bit concerned more with practical issues.  Generally, typedefs
can fix the unreadable (IMHO) some_unit_t, like in the FermiLab software for
Length, Width, Area, etc.  And clearly the "cm" is a object and thus takes
up some space in run-time code where as your approach, in not allowing type
qualifiers, makes the code lean and mean.  IMHO, again I like the
"modifiers" approach for building numbers, but to do so in such a way that
they can be included modularly: if you don't use it, you don't pay for it.
A hybrid between your Spartan impl and Fermi's bloated one is what I'd
prefer as far as code readability.

Now, as for output, I have to admit preference to a different approach.
Basically, as I see it there should be unit types (Mass, Volume, Time,
Luminescence, [Electric] Current, Temperature per Radian, etc.) as well as
units (kg, l, yr, cd, a, K/r) and that the former should be true types and
the later a modifier for immediates.  Note also that although SI does not re
cognize the dimensionless Radian and Striation, I think as a part-time
physicist I'd like to know when I'm dealing with "radian per second" it is
not confused with Hz (cycles [1] per second).  But for output, what strikes
me is how you have each type return its representation.  Granted, this is
part of a "Policy" which I think is the right approach, but OTOH, I am
currently of the mind that std::facet is an underused aspect of the standard
library.  IMHO the representation of kiloliters or meters cubed or m^3 or
m**3 or m3 should be configurable via imbuing the output with a facet based
on unitRepresentation : public std::facet.  Then, to change the output one
can derive a class from unitRepresentation replacing "K" with "*K" or "K*"
depending on the programmer's preference.  Granted this is the same
mechanism I would use to create a custom kelvinPolicy-derived class to
replace the representation, but to me I like the idea of abstracting the
output from the type.

As for unit conversions, I think this, like any scientific Unit library in
general, requires a "significant_digit" library like the one on which I am
working.  Thus, as I have already greatly researched, converting between lb
and force-kg (kN) would be only as accurate as either a) your source data or
b) the conversion factor (about 7 digits IIRC).  I have already implemented
a library based on the assumption that 2 numbers with given error x+/-dx,
y+/-dy can be manipulated in any of the built-in operations including sin,
exp, etc. under the assumption that x and y are both independent, random
variables.  If there is a dependant relationship between x and y, I would
have to take the partial derivatives of xdy and ydx (normally 0) into
account.  This would then have to be implemented as a "sci_number" policy
IMHO, but that is another thing I will save for later.  Your library would
allow abstract data types on the fly as it were, unlike FermiLab which has
the type compiled in to the library.  I would therefore only caution that
Unit Conversion should be easily separable (another Policy??) from the
unit-library proper to allow for those who want numbers with errors and
those who don't.

I think that is all, but in any case thanks Vladimir for bringing this to
our attention!  It is IMHO a cool thing to add.

Jeffrey.

"vladimir josef sykora" <vladimir.sykora_at_[hidden]> wrote in message
news:aok5bc$ne4$1_at_main.gmane.org...
> Greetings boosters,
> I've been working for some time now on a physical unit's library that I'd
> like to submit to boost. It uses the concept of generating units out of
> physical dimensions. It provides type-safety and implicit conversion
between
> units using operators.
>
[more...]