Re: quantity libraries

From: Michael Kenniston (Msk_at_[hidden])
Date: 2001-08-11 00:05:47

John (EBo) David wrote:

> is the new version the one dated 7/13/2001?

Yes, that one (quantity_0_3.zip) is the most recent version.

Thomas Matelich wrote:

> I guess I'm asking for more of the features of SIUnits while still
> maintaining the portability.

A perfectly reasonable request, IMHO.  The code I uploaded to the
files area, while functional, was really intended as "discussion
fodder," and it did generate a fair bit of discussion and some
interesting suggestions.  You are of course welcome to use it, but
I don't feel it's nearly complete enough yet to submit for formal
review.

I'm also waiting to see if the latest version of SIunits will
be submitted to boost.  My understanding is that the version on
Fermilab's public web site is quite a bit behind the current
version used internally, and that the author was going to work
on getting some kind of administrative approval to release the
latest-and-greatest.

Until/unless that happens, and as I have time, I'll try to keep
working on my version.  The first thing that should probably be
done is to change the function syntax to variable syntax for all
the predefined units (e.g. change "meter()" to "meter") using
the trick described in
  http://groups.yahoo.com/group/boost/message/14867
It also needs more portability testing, for which I'm in the
process of installing three more C++ compilers on my new PC.
Hopefully in the next week or two I'll get a new version uploaded.

Between SIunits, Quantity, and the code from Barton & Nackman's
book (which I haven't actually seen yet, but a copy is supposed
to appear in my mailbox any day now), I would guess that boost
might have something solid to review in the autumn-ish time frame.

Thomas Matelich also wrote:

> One of the features I'm looking for in a quantity/units library is
less of a focus on
> the math side of things and more of a localization, i.e. the customer
gets to decide
> what units to use.  So, the feature that I would want would be the
unit of measurement
> being stored along with the quantity.  I could, I suppose, translate
all user
> interaction through a localizer, but that introduces a lot of
conversions.  Why should
> someone who wants to use feet be forced to convert to/from meters
every time?

I'm not quite sure what you mean here.  I can think of at least four
possible responses, all of which are at least moderately interesting:

1) The user has to use the explicit syntax:

    length_t x = 3 * foot;
    length_t y( 4 * foot );

instead of:

    length_t x = 3;
    length_t y( 4 );

This is quite deliberate.  Allowing the second form opens a hole in
the compile-time type-checking that invites errors.  The first form
isn't /that/ much more to type, and it is /much/ clearer to anyone
reading the code.  Note that the word "meter" never appears in the
application source code unless the user actually uses meters.

2) The program incurs a run-time conversion cost when it executes:

    length_t x = 3 * foot;

because there is a real multiply there.  This is indeed overhead, but
my expectation is that such "real" conversions only happen on input
and output, and the cost of buffered I/O and string-to-numeric
conversion should swamp the single multiplication necessary to do
the conversion.  If this is really truly a problem, adding something
similar to the SIunits "calibration" feature might help, but I'd
want to see hard performance data proving its necessity.

3) You could save the units with each quantity, and do a "lazy
conversion" only if and when it becomes necessary.  This would
bloat the size of every quantity object and impose a run-time
cost to do unit-comparison on every single operation, thereby
defeating the whole purpose of using templates, so I rejected
this idea completely.

4) In between "units" and "dimensionality" there is a third distinct
concept of "quantity-type".  For example "radian", "mil_angle", and
"degree_angle" are different units but have the same quantity type
(plane angle) and are thus freely convertible.  However "pure number"
and "plane angle" are different types, even though they have the same
dimensionality, and so should not be freely convertible.  My intuition
is that this concept would be very useful, but at this time I have no
clear idea how to implement it (or even define it) correctly, so I'd
rather concentrate on just getting dimension-checking right to start
with.

If none of this addressed your original question, could you provide
a specific example of code where the user is "forced to convert to/from
meters every time"?

--
- Michael Kenniston
  mkenniston_at_[hidden]
  msk_at_[hidden]    http://www.xnet.com/~msk/